Re: [ovs-discuss] vlan id inequality matching

[Ben Pfaff]

On Wed, Jan 24, 2018 at 01:54:32PM -0500, John Lester wrote:
> What would be the way to express in a flow: match all vlans except vlan
> 405. Would it be vlan_vid=0/405 or perhaps another way?

That approach won't work.

The simplest way is to use two flows: one with a high priority that
matches VLAN 405 and does whatever should be done to packets in that
VLAN, and another one (or more) with lower priority to handle packets
with other VLANs.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Lost in translation! OFP to DPDK datapath OVS actions?

[Ben Pfaff]

Maybe.  Sometimes it's too hard to keep track of changes just by looking
at the flow.

On Wed, Jan 24, 2018 at 08:18:12PM +0100, Alan Kayahan wrote:
> Thanks for bearing with me so far Ben. I will post my experience in
> creating a custom action and match step by step like some others have done
> in the mailing list, both for hearing your input and for others to benefit.
> 
> What if the action is creating a new header, an IPv6 extension header, in
> the packet? My OVS action is pushing the L2+L3 headers in the packet
> buffer, making enough room for say the fragmentation header, then appending
> the header and readjusting the L4 offset. In this case, does it make sense
> to immediately emit ODP action via "nl_msg_put_u16(ctx->odp_actions,
> OVS_ACTION_ATTR_PUSH_EXTH, ofpact_get_PUSH_EXTH(a)->arg);" in
> ofproto-dpif-xlate?
> 
> 
> 2018-01-22 20:33 GMT+01:00 Ben Pfaff <b...@ovn.org>:
> 
> > Actions that just set fields don't emit ODP actions to do that
> > immediately because controllers often change fields multiple times
> > between outputs, so that it would be wasteful to emit the changes
> > multiple times.  Instead, at the time of emitting an output (or other
> > visible side effect), OVS emits all changes to fields in one group.
> >
> > On Sat, Jan 13, 2018 at 09:11:50AM +0100, Alan Kayahan wrote:
> > > Indeed. My custom action works when I put nl_msg_put_flag(ctx->odp_
> > actions,
> > > OVS_ACTION_ATTR_MY_ACTION); however none of the other cases follow this
> > > pattern. They all set flow->xxx from the struct casted ofpact instead.
> > > Since both setting ctx->odp_actions and flow->xxx works, I have the
> > > following questions
> > >
> > > 1) Where do the actions defined in ctx->odp_actions get actuated?
> > > 2) Where do the actions for the struct flow get actuated, and how does
> > the
> > > actuator know what OVS actions to actuate?
> > > 3) Can we say that do_xlate_actions() is currently being used outside the
> > > purpose that its name implies, because all it does is to set the fields
> > of
> > > the struct flow to those set in ofpact struct?
> > >
> > > Thanks
> > >
> > > 2018-01-12 18:36 GMT+01:00 Ben Pfaff <b...@ovn.org>:
> > >
> > > > On Fri, Jan 12, 2018 at 11:39:44AM +0100, Alan Kayahan wrote:
> > > > > Hello,
> > > > >
> > > > > Per my understanding from /ovs-discuss/2015-May/037313.html,
> > > > > ofproto-dpif-xlate translates OFP actions into Netlink format, which
> > is
> > > > > useful for datapath actions implemented in the kernel module. Does
> > that
> > > > > hold for OFP to DPDK datapath actions too?
> > > >
> > > > Yes.
> > > >
> > > > > I couldn't find a connection from ofproto-dpif-xlate to
> > > > > odp_execute_actions. Where does the translation of ofpact structs
> > into
> > > > > OVS actions implemented in DPDK datapath take place?
> > > >
> > > > ofproto-dpif-xlate does the translation for both datapaths, in the same
> > > > way.
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS delete port by itself

[Ben Pfaff]

On Tue, Jan 23, 2018 at 10:41:21AM +0800, netsurfed wrote:
> Hi all,
> 
> 
> When I created a virtual machine using libvirt, with virtualport type was 
> openvswitch, and virtual machine creation failed. The Domain XML file the 
>  section like this:
> 
> 
> I looked at the system log and it looked like an ovs port problem.
> 
> 
> And the ovs-vswitchd.log was:
> 
> 
> Is there any reason for this problem? Thank you very much.
> Below some information about my machine:
> ovs_version: "2.8.90"
> root@ubuntu-24:~# uname -a
> Linux ubuntu-24 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux

Your image shows that libvirtd is calling into tc and hitting an error.
Then, something (probably libvirtd again) calls "ovs-vsctl del-port".
This therefore appears to be a problem in libvirtd; OVS is just doing
what it's told.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Windows test: 1077. ofproto-dpif.at:1663: testing ofproto-dpif - controller action without megaflows

[Ben Pfaff]

Certainly these are odd results showing that on Windows an extra packet
passes through the rate limiter.  Do you have any leads on a possible
solution?  Does timing work somehow different on Windows?

On Sun, Jan 14, 2018 at 05:11:00PM +, Alin Serdean wrote:
> ofproto-dpif
> 
> 1077. ofproto-dpif.at:1663: testing ofproto-dpif - controller action without 
> megaflows ...
> ./ofproto-dpif.at:1664: ovsdb-tool create conf.db 
> $abs_top_srcdir/vswitchd/vswitch.ovsschema
> ./ofproto-dpif.at:1664: ovsdb-server --detach --no-chdir --pidfile --log-file 
> --remote=punix:$OVS_RUNDIR/db.sock
> stderr:
> ./ofproto-dpif.at:1664: sed < stderr '
> /vlog|INFO|opened log file/d
> /ovsdb_server|INFO|ovsdb-server (Open vSwitch)/d'
> ./ofproto-dpif.at:1664: ovs-vsctl --no-wait init
> ./ofproto-dpif.at:1664: ovs-vswitchd --enable-dummy --disable-system  
> --detach --no-chdir --pidfile --log-file -vvconn -vofproto_dpif -vunixctl
> stderr:
> ./ofproto-dpif.at:1664: sed < stderr '
> /ovs_numa|INFO|Discovered /d
> /vlog|INFO|opened log file/d
> /vswitchd|INFO|ovs-vswitchd (Open vSwitch)/d
> /reconnect|INFO|/d
> /ofproto|INFO|using datapath ID/d
> /netdev_linux|INFO|.*device has unknown hardware address family/d
> /ofproto|INFO|datapath ID changed to fedcba9876543210/d
> /dpdk|INFO|DPDK Disabled - Use other_config:dpdk-init to enable/d
> /netdev: Flow API/d
> /tc: Using policy/d'
> ./ofproto-dpif.at:1664: add_of_br 0
> ovs-vsctl -- add-port br0 p1 -- set Interface p1 type=dummy ofport_request=1
> ./ofproto-dpif.at:1667: ovs-ofctl add-flow br0 in_port=1,action=controller
> ./ofproto-dpif.at:1668: ovs-appctl upcall/disable-megaflows
> ./ofproto-dpif.at:1673: ovs-ofctl monitor br0 65534 invalid_ttl -P 
> nxt_packet_in --detach --no-chdir --pidfile 2> ofctl_monitor.log
> ./ofproto-dpif.at:1676: ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x1234)'
> ./ofproto-dpif.at:1676: ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x1234)'
> ./ofproto-dpif.at:1682: ovs-appctl dpctl/dump-flows | sed 
> 's/.*\(packets:\)/\1/' | sed 's/used:[0-9].[0-9]*s/used:0.001s/'
> ./ofproto-dpif.at:1687: cat ofctl_monitor.log
> ./ofproto-dpif.at:1694: ovs-appctl revalidator/purge
> ./ofproto-dpif.at:1695: ovs-ofctl monitor br0 65534 invalid_ttl -P 
> nxt_packet_in --detach --no-chdir --pidfile 2> ofctl_monitor.log
> ./ofproto-dpif.at:1698: ovs-ofctl -O OpenFlow13 add-meter br0 
> 'meter=controller pktps stats bands=type=drop rate=2'
> ./ofproto-dpif.at:1701: ovs-appctl time/warp 1000
> stdout:
> warped
> ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x4321)'
> ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x4321)'
> ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x4321)'
> ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x4321)'
> ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x4321)'
> ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x4321)'
> ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x4321)'
> ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x4321)'
> ./ofproto-dpif.at:1707: ovs-appctl dpctl/dump-flows | sed 
> 's/.*\(packets:\)/\1/' | sed 's/used:[0-9].[0-9]*s/used:0.001s/'
> ./ofproto-dpif.at:1712: ovs-appctl time/warp 1
> stdout:
> warped
> ./ofproto-dpif.at:1717: cat ofctl_monitor.log
> --- -   2018-01-14 19:07:32 +0200
> +++ /c/_2018/january/14/ovs/tests/testsuite.dir/at-groups/1077/stdout   
> 2018-01-14 19:07:33 +0200
> @@ -2,4 +2,6 @@
>  
> vlan_tci=0x,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,dl_type=0x4321
>  NXT_PACKET_IN (xid=0x0): cookie=0x0 total_len=14 in_port=1 (via action) 
> data_len=14 (unbuffered)
>  
> vlan_tci=0x,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,dl_type=0x4321
> +NXT_PACKET_IN (xid=0x0): cookie=0x0 total_len=14 in_port=1 (via action) 
> data_len=14 (unbuffered)
> +vlan_tci=0x,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,dl_type=0x4321
> ___
> 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] Lost in translation! OFP to DPDK datapath OVS actions?

[Ben Pfaff]

Actions that just set fields don't emit ODP actions to do that
immediately because controllers often change fields multiple times
between outputs, so that it would be wasteful to emit the changes
multiple times.  Instead, at the time of emitting an output (or other
visible side effect), OVS emits all changes to fields in one group.

On Sat, Jan 13, 2018 at 09:11:50AM +0100, Alan Kayahan wrote:
> Indeed. My custom action works when I put nl_msg_put_flag(ctx->odp_actions,
> OVS_ACTION_ATTR_MY_ACTION); however none of the other cases follow this
> pattern. They all set flow->xxx from the struct casted ofpact instead.
> Since both setting ctx->odp_actions and flow->xxx works, I have the
> following questions
> 
> 1) Where do the actions defined in ctx->odp_actions get actuated?
> 2) Where do the actions for the struct flow get actuated, and how does the
> actuator know what OVS actions to actuate?
> 3) Can we say that do_xlate_actions() is currently being used outside the
> purpose that its name implies, because all it does is to set the fields of
> the struct flow to those set in ofpact struct?
> 
> Thanks
> 
> 2018-01-12 18:36 GMT+01:00 Ben Pfaff <b...@ovn.org>:
> 
> > On Fri, Jan 12, 2018 at 11:39:44AM +0100, Alan Kayahan wrote:
> > > Hello,
> > >
> > > Per my understanding from /ovs-discuss/2015-May/037313.html,
> > > ofproto-dpif-xlate translates OFP actions into Netlink format, which is
> > > useful for datapath actions implemented in the kernel module. Does that
> > > hold for OFP to DPDK datapath actions too?
> >
> > Yes.
> >
> > > I couldn't find a connection from ofproto-dpif-xlate to
> > > odp_execute_actions. Where does the translation of ofpact structs into
> > > OVS actions implemented in DPDK datapath take place?
> >
> > ofproto-dpif-xlate does the translation for both datapaths, in the same
> > way.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] vPort state

[Ben Pfaff]

On Thu, Jan 18, 2018 at 11:37:57AM +, Nitin Katiyar wrote:
> Can someone help in understanding the reason for not allowing the
> vport state to DOWN.  Presently, if we try to bring down tunnel ports
> (or vPorts) using "ovs-ofctl mod-port" command then OVS rejects it as
> "not supported".

I think it just isn't implemented.  I don't know a reason we wouldn't
accept an implementation.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Linking of OFPROTO and NETDEV libraries to OVS

[Ben Pfaff]

On Mon, Jan 22, 2018 at 07:06:59AM +0530, Aravind Prasad wrote:
> Hi Ben,
> 
> > I don't understand the question.  These are always linked together.
> 
> I want to write a new ofproto provider and netdev provider and have them as
> dynamic libraries. The requirement is to have the implementation of the
> provider Apis  contained in a separate dynamic library and not modify ovs
> code base by adding private patches to register providers.
> Hence, with this, I can download the OVS-Package, replace the dynamic
> library for registering providers and start using OVS without touching the
> OVS code base.
> 
> Is the above possible today? Thanks for the response and support.

OVS doesn't support that.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Regarding adding flows on a remote switch using ovs-ofctl

[Ben Pfaff]

You seem to be confusing things.  "OpenFlow connections" and "controller
connections" are the same thing, and the --db option to ovs-vsctl is
entirely different.

On Sun, Jan 21, 2018 at 04:57:48PM -0600, Ashish Kashinath wrote:
> Okay, I see, it makes sense. So is it that the switch should have an
> additional port listening for openflow connections using ptcp (in addition
> to the port listening to controller connections)?
> 
> I guess this should be a ovs-vsctl command on the lines of
> 
> ovs-vsctl --db=tcp::
> 
> Is that right?
> 
> On Sun, Jan 21, 2018 at 3:15 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > On Sun, Jan 21, 2018 at 02:17:56PM -0600, Ashish Kashinath wrote:
> > > Hi everyone, we were trying to add flows to a switch remotely via tcp.
> > But
> > > are not able to do so. The command we used is:
> > >
> > > *ak7@ubuntu:~/Repositories/qos_synthesis/src/experiments$ ovs-ofctl
> > > add-flow tcp:192.168.1.101 action=normal*
> > > *2018-01-21T19:23:21Z|1|stream|WARN|The default OpenFlow port number
> > > has changed from 6633 to 6653*
> > > *ovs-ofctl: tcp:192.168.1.101 <http://192.168.1.101>: failed to connect
> > to
> > > socket (Connection refused)*
> > >
> > > At the switch command line, we use the ovs-vsctl set-controller to ensure
> > > the switch is listing to openflow commands The command we used is:
> > >
> > > *ovs-vsctl set-controller br0 tcp:192.168.1.102:6633
> > > <http://192.168.1.102:6633>*
> > >
> > > 192.168.1.101 is the IP address of our switch running ovs.
> > > 192.168.1.102 is the IP address of the controller.
> >
> > You have both sides connecting outbound, but one side needs to be
> > listening for a connection (with ptcp:).
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Regarding adding flows on a remote switch using ovs-ofctl

[Ben Pfaff]

On Sun, Jan 21, 2018 at 02:17:56PM -0600, Ashish Kashinath wrote:
> Hi everyone, we were trying to add flows to a switch remotely via tcp. But
> are not able to do so. The command we used is:
> 
> *ak7@ubuntu:~/Repositories/qos_synthesis/src/experiments$ ovs-ofctl
> add-flow tcp:192.168.1.101 action=normal*
> *2018-01-21T19:23:21Z|1|stream|WARN|The default OpenFlow port number
> has changed from 6633 to 6653*
> *ovs-ofctl: tcp:192.168.1.101 : failed to connect to
> socket (Connection refused)*
> 
> At the switch command line, we use the ovs-vsctl set-controller to ensure
> the switch is listing to openflow commands The command we used is:
> 
> *ovs-vsctl set-controller br0 tcp:192.168.1.102:6633
> *
> 
> 192.168.1.101 is the IP address of our switch running ovs.
> 192.168.1.102 is the IP address of the controller.

You have both sides connecting outbound, but one side needs to be
listening for a connection (with ptcp:).
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Linking of OFPROTO and NETDEV libraries to OVS

[Ben Pfaff]

On Fri, Jan 19, 2018 at 10:15:46AM +0530, Aravind Prasad wrote:
> Is there a way to link OFPROTO and NETDEV libraries directly to OVS binary
> without recompiling the OVS codebase. Like, downloading the OVS debian
> binary directly and link the ofproto and netdev dynamic libraries to it.

I don't understand the question.  These are always linked together.

> Afaik, currently, we need to compile the OVS code with ofproto and netdev
> libraries manually. And if thats the way, is supporting multiple datapath
> elements the possible reason to mandate the recompilation of OVS codebase
> with the libraries. Just curious to know :).
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] In 'OVS Faucet Tutorial', router does not work as expected at 'Step 4: Router Broadcasts ARP Request'

[Ben Pfaff]

I sent a series that adds these features:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=24270

On Thu, Jan 18, 2018 at 09:34:40AM +1300, Brad Cowie wrote:
> We've had a bit of a think about this, variable length probably isn't too
> important (static 64b is probably fine), but yes, being able to set those
> 64 bytes will be quite useful with say with an extra "payload=0xC0FEFE"
> argument on ofproto/trace.
> 
> Brad
> 
> On 18 January 2018 at 07:17, Ben Pfaff <b...@ovn.org> wrote:
> 
> > OK, sounds good.
> >
> > Do you think you need the ability to inject payloads of a specific
> > length or content?  It's easy to, for example, always generate 64 bytes
> > of payload, but it would be a little more challenging to plumb through
> > extra data or metadata.
> >
> > On Mon, Jan 15, 2018 at 01:48:10PM +1300, Brad Cowie wrote:
> > > Hi Ben,
> > >
> > > We looked a bit closer at this problem, and turns out the packet header
> > > size we were getting back from Ryu wasn't what we were expecting. We're
> > now
> > > calculating this correctly ourselves (instead of relying on Ryu) which
> > > removes the need for disabling the IP header length check in the tutorial
> > > (I've send another patch towards d...@openvswitch.org that does this).
> > >
> > > As for being able to inject payload into ofproto/trace generated packets
> > I
> > > think this would be quite useful for folks like us. We are looking at
> > > moving our test suite to using ofproto/trace to generate packets (instead
> > > of scapy) for throwing at test scenarios because it's considerably more
> > > lightweight and we are already using openvswitch as the core of our test
> > > suite.
> > >
> > > Brad
> > >
> > > On 9 January 2018 at 05:51, Ben Pfaff <b...@ovn.org> wrote:
> > >
> > > > [dropping OP, who probably doesn't care]
> > > >
> > > > On Sat, Jan 06, 2018 at 12:07:09PM +1300, Brad Cowie wrote:
> > > > > What happened is that in faucet 1.6.12 we added a bunch of new packet
> > > > > handling sanity checks to help improve security of faucet's packet
> > > > > handling. Packets made by ofproto/trace -generate will have a
> > zero-length
> > > > > payload which trips some of our sanity checks which will cause us to
> > drop
> > > > > the packet.
> > > >
> > > > If OVS generated a packet with some nonzero size payload, would that
> > fix
> > > > the problem?  It's easy for us to change the details, we would just add
> > > > some code to flow_compose_l4() in lib/flow.c to put some L7 data into
> > > > the UDP packet.
> > > >
> > > > I suspect that changing the tutorial from using UDP to TCP might also
> > > > work around the issue?  After all, TCP packets with empty payloads are
> > > > pretty common, at least (off the top of my head) if they have SYN or
> > FIN
> > > > or RST attached.
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS port name differ from interface name

[Ben Pfaff]

Maybe you want it to be an "internal" port:
ovs-vsctl set interface  type=internal

On Thu, Jan 18, 2018 at 02:17:03PM +0100, Riccardo Ravaioli wrote:
> Hi Ben,
> 
> I have a related question. I do the following in order to have a bridge br
> with ports 0.br, 1.br... and later add existing interfaces to such ports:
> 
> ovs-vsctl add-br br
> ovs-vsctl add-port br 0.br
> ovs-vsctl --id=@ifce create interface  name=eth1 -- set port 0.br
> interface=@ifce
> 
> When I execute the "ovs-vsctl add-port' command above I get an error saying
> that 0.br doesn't correspond to any interface:
> *ovs-vsctl: Error detected while setting up '0.switch5': could not open
> network device 0.switch5 (No such device).*
> 
> Can I pass an argument to "ovs-vsctl add-port" to tell OVS that 0.br is
> just a switch port and not a real existing interface?
> 
> 
> __
> 
> 
> On 15 January 2018 at 20:19, Ben Pfaff <b...@ovn.org> wrote:
> 
> > On Mon, Jan 15, 2018 at 09:50:52AM -0800, Fred Licht wrote:
> > >Is it possible to have an OVS port ‘name’ differ from the interface
> > name?
> > >
> > > Bridge ovs-ha-sw
> > > Port ovs-ha-sw
> > > Interface ovs-ha-sw
> > > type: internal
> > > Port "bond1"
> > > Interface "bond1"
> > >
> > > To have the effect of:
> > >
> > > Bridge ovs-ha-sw
> > > Port ovs-ha-sw
> > > Interface ovs-ha-sw
> > > type: internal
> > > Port “east-west"
> > > Interface "bond1"
> >
> > You can do it, but since port names are immutable it has to happen at
> > the time you add the port.  For example:
> >
> > blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-br br0
> > blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-port br0 p0 -- set
> > port p0 name=asdf
> > blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl show
> > 8b75cccb-f1eb-4e75-ac67-57ebac4e8432
> > Bridge "br0"
> > Port "br0"
> > Interface "br0"
> > type: internal
> > Port asdf
> > Interface "p0"
> > blp@sigabrt:~/nicira/ovs/tutorial(0)$
> > ___
> > 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] DB operations in a OVSDB request and Batched requests.

[Ben Pfaff]

On Sun, Jan 14, 2018 at 01:41:36PM -0800, Anil Jangam wrote:
> Hi,
> 
> The "transact" method of OVSDB protocol mandates the sequential processing
> of the transaction. It is specificed in section 4.1.3 as follows.
> 
>The database server executes each of the specified operations in
> the specified
>order, except if an operation fails, then the remaining operations
>are not executed.  The set of operations is executed as a single
>atomic, consistent, isolated transaction.  The transaction is
>committed if and only if every operation succeeds.
> 
> 
> In the context of this struct ordering requirement, does OVSDB protocol
> allows for parallel execution of multiple OVSDB request processing?

Yes, from the same client or different clients.

> Does the controller sends multiple requests in parallel, or in other words,
> does it sends one request before receiving the result of the previous
> request?

The controller can send multiple requests before receiving their
results.  Not all controllers take advantage of this.

> JSON_RPC specification 2.0 specifies the BATCH of requests, which can be
> executed in parallel; however, I am not sure if OVSDB protocol recommends
> the use of JSON_RPC 2.0.

The ovsdb-server implementation currently supports only JSON-RPC 1.0.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] In 'OVS Faucet Tutorial', router does not work as expected at 'Step 4: Router Broadcasts ARP Request'

[Ben Pfaff]

OK, sounds good.

Do you think you need the ability to inject payloads of a specific
length or content?  It's easy to, for example, always generate 64 bytes
of payload, but it would be a little more challenging to plumb through
extra data or metadata.

On Mon, Jan 15, 2018 at 01:48:10PM +1300, Brad Cowie wrote:
> Hi Ben,
> 
> We looked a bit closer at this problem, and turns out the packet header
> size we were getting back from Ryu wasn't what we were expecting. We're now
> calculating this correctly ourselves (instead of relying on Ryu) which
> removes the need for disabling the IP header length check in the tutorial
> (I've send another patch towards d...@openvswitch.org that does this).
> 
> As for being able to inject payload into ofproto/trace generated packets I
> think this would be quite useful for folks like us. We are looking at
> moving our test suite to using ofproto/trace to generate packets (instead
> of scapy) for throwing at test scenarios because it's considerably more
> lightweight and we are already using openvswitch as the core of our test
> suite.
> 
> Brad
> 
> On 9 January 2018 at 05:51, Ben Pfaff <b...@ovn.org> wrote:
> 
> > [dropping OP, who probably doesn't care]
> >
> > On Sat, Jan 06, 2018 at 12:07:09PM +1300, Brad Cowie wrote:
> > > What happened is that in faucet 1.6.12 we added a bunch of new packet
> > > handling sanity checks to help improve security of faucet's packet
> > > handling. Packets made by ofproto/trace -generate will have a zero-length
> > > payload which trips some of our sanity checks which will cause us to drop
> > > the packet.
> >
> > If OVS generated a packet with some nonzero size payload, would that fix
> > the problem?  It's easy for us to change the details, we would just add
> > some code to flow_compose_l4() in lib/flow.c to put some L7 data into
> > the UDP packet.
> >
> > I suspect that changing the tutorial from using UDP to TCP might also
> > work around the issue?  After all, TCP packets with empty payloads are
> > pretty common, at least (off the top of my head) if they have SYN or FIN
> > or RST attached.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] clustered OVSDB in 2.9 or 2.10?

[Ben Pfaff]

On Mon, Jan 15, 2018 at 08:46:50AM -0500, Russell Bryant wrote:
> On Mon, Jan 15, 2018 at 2:30 AM, Numan Siddique <nusid...@redhat.com> wrote:
> >
> >
> > On Fri, Jan 12, 2018 at 1:28 AM, Ben Pfaff <b...@ovn.org> wrote:
> >>
> >> I posted the patches to add clustering support to OVSDB at the end of
> >> last year so that it was technically qualified to make it into OVS 2.9.
> >> At least in OVS 2.9, it will be marked "experimental", since it's a
> >> major change that might need work to be suitable for production (we
> >> simply don't know yet).  Since it's a huge change, review is naturally
> >> taking a while.
> >>
> >> It occurred to me that it might make more sense to get this into master
> >> just after we branch for 2.9.  Then it would be basically the first
> >> feature in 2.10.  That would give us the whole 2.10 release cycle to get
> >> it from experimental to something production quality, and we could in
> >> theory release 2.10 with a solid clustered OVSDB.  Instead of
> >> experimental in 2.9 and then production in 2.10, we'd just have
> >> production in 2.10.  That might also give us some opportunity to make
> >> breaking changes within the 2.10 cycle that users who were experimenting
> >> with 2.9 might be reluctant to accept as part of an upgrade.
> >>
> >> Does anyone have thoughts on which is the preferred path?
> >
> >
> > Hi Ben,
> >
> > I see one advantage for OpenStack Tripleo + OVN integration in having this
> > feature
> > supported as expiremental in OVS 2.9.  Once we have OVS 2.9 availalbe in RDO
> > packages
> > we could work on integrating this feature (as optional) during OVN
> > deployments. The scope of
> > this work would be to start OVN db services with clustering enabled and
> > configuring it.
> > The next OpenStack release is Queens and is under development, but we are
> > already late for new
> > features so it is fine. The release after Queens is Rocky and it will be
> > easier to integrate
> > clustered ovsdb feature with Rocky release if we have it in OVS 2.9.
> 
> This is the main benefit of putting it in 2.9 to me -- it makes it
> easier to work on integration.
> 
> If it's in 2.9, OpenStack (as one example) can do integration work and
> merge it as an optional feature.  If it's deferred to 2.10, that work
> can begin, but the patches can't be merged until the feature is in a
> release.  It's also a bit more difficult to test it in integrated CI
> until it's in a release.
> 
> It's also understandable if 2.9 turns out to be too aggressive.

OK.  We'll see how the reviews go.  If it doesn't seem like it's going
to be totally last minute or actually delay 2.9, I'll get it in.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS port name differ from interface name

[Ben Pfaff]

On Mon, Jan 15, 2018 at 09:50:52AM -0800, Fred Licht wrote:
>Is it possible to have an OVS port ‘name’ differ from the interface name?
> 
> Bridge ovs-ha-sw
> Port ovs-ha-sw
> Interface ovs-ha-sw
> type: internal
> Port "bond1"
> Interface "bond1"
> 
> To have the effect of:
> 
> Bridge ovs-ha-sw
> Port ovs-ha-sw
> Interface ovs-ha-sw
> type: internal
> Port “east-west"
> Interface "bond1"

You can do it, but since port names are immutable it has to happen at
the time you add the port.  For example:

blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-br br0
blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-port br0 p0 -- set port p0 
name=asdf
blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl show
8b75cccb-f1eb-4e75-ac67-57ebac4e8432
Bridge "br0"
Port "br0"
Interface "br0"
type: internal
Port asdf
Interface "p0"
blp@sigabrt:~/nicira/ovs/tutorial(0)$ 
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Lost in translation! OFP to DPDK datapath OVS actions?

[Ben Pfaff]

On Fri, Jan 12, 2018 at 11:39:44AM +0100, Alan Kayahan wrote:
> Hello,
> 
> Per my understanding from /ovs-discuss/2015-May/037313.html,
> ofproto-dpif-xlate translates OFP actions into Netlink format, which is
> useful for datapath actions implemented in the kernel module. Does that
> hold for OFP to DPDK datapath actions too? 

Yes.

> I couldn't find a connection from ofproto-dpif-xlate to
> odp_execute_actions. Where does the translation of ofpact structs into
> OVS actions implemented in DPDK datapath take place?

ofproto-dpif-xlate does the translation for both datapaths, in the same
way.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] clustered OVSDB in 2.9 or 2.10?

[Ben Pfaff]

I posted the patches to add clustering support to OVSDB at the end of
last year so that it was technically qualified to make it into OVS 2.9.
At least in OVS 2.9, it will be marked "experimental", since it's a
major change that might need work to be suitable for production (we
simply don't know yet).  Since it's a huge change, review is naturally
taking a while.

It occurred to me that it might make more sense to get this into master
just after we branch for 2.9.  Then it would be basically the first
feature in 2.10.  That would give us the whole 2.10 release cycle to get
it from experimental to something production quality, and we could in
theory release 2.10 with a solid clustered OVSDB.  Instead of
experimental in 2.9 and then production in 2.10, we'd just have
production in 2.10.  That might also give us some opportunity to make
breaking changes within the 2.10 cycle that users who were experimenting
with 2.9 might be reluctant to accept as part of an upgrade.

Does anyone have thoughts on which is the preferred path?

Thanks,

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

Re: [ovs-discuss] how to add an interface to exists bonding port?

[Ben Pfaff]

On Tue, Jan 09, 2018 at 02:59:33PM +0800, cokabug wrote:
> I have a bonding port : bond0 that contain two interface : eth0 eth1,
> now i want to add eth2 to bond0 without network interrupt, how can i do
> this,
> i try the command :
>   ovs-vsctl --may-exist add-bond br-f2b0711 bond0  eth0 eth1 eth2
> or
>   ovs-vsctl --may-exist add-bond br-f2b0711 bond0 eth1 eth2
> 
> result is : ovs-vsctl: "--may-exist add-bond br-f2b0711 bond0 eth1
> eth2" but bond0 actually has interface(s) eth0

You can probably achieve the effect you want by deleting and re-adding
the port in a single transaction, e.g.:

ovs-vsctl del-port bond0 -- add-bond br-f2b0711 bond0 eth0 eth1 eth2
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] In 'OVS Faucet Tutorial', router does not work as expected at 'Step 4: Router Broadcasts ARP Request'

[Ben Pfaff]

[dropping OP, who probably doesn't care]

On Sat, Jan 06, 2018 at 12:07:09PM +1300, Brad Cowie wrote:
> What happened is that in faucet 1.6.12 we added a bunch of new packet
> handling sanity checks to help improve security of faucet's packet
> handling. Packets made by ofproto/trace -generate will have a zero-length
> payload which trips some of our sanity checks which will cause us to drop
> the packet.

If OVS generated a packet with some nonzero size payload, would that fix
the problem?  It's easy for us to change the details, we would just add
some code to flow_compose_l4() in lib/flow.c to put some L7 data into
the UDP packet.

I suspect that changing the tutorial from using UDP to TCP might also
work around the issue?  After all, TCP packets with empty payloads are
pretty common, at least (off the top of my head) if they have SYN or FIN
or RST attached.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Any timeline on PISCES in the mainline OVS?

[Ben Pfaff]

On Wed, Jan 03, 2018 at 08:54:25PM +0100, Alan Kayahan wrote:
> I read about PISCES and watched its presentation. The presenter mentioned
> that the PISCES is expected to be in the mainline OVS. Is there any news
> regarding that, or regarding any kind of P4 integration?

It's a goal of mine for 2.10.

> Would it be appropriate to use this mailing list to ask questions about
> PISCES as its git looks rather dormant?

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

Re: [ovs-discuss] ovn-controller consuming lots of CPU

[Ben Pfaff]

On Tue, Dec 12, 2017 at 01:26:33PM -0800, Kevin Lin wrote:
> Hi again,
> 
> We’re trying to scale up our OVN deployment and we’re seeing some worrying 
> log messages. 
> The topology is 32 containers connected to another 32 containers on 10 
> different ports. This is running on 17 machines (one machine runs ovn-northd 
> and ovsdb-server, the other 16 run ovn-controller, ovs-vswitchd, and 
> ovsdb-server). We’re using an address set for the source group, but not the 
> destination group. We’re also creating a different ACL for each port. So the 
> ACLs look like:
> One address set for { container1, container2, … container32 }
> addressSet -> container1 on port 80
> addressSet -> container1 on port 81
> …
> addressSet -> container1 on port 90
> addressSet -> container2 on port 80
> …
> addressSet -> container32 on port 90

Hmm, can you help me understand better what's going on?  I'd like to
help.

It sounds like this strategy for setting up ACL entries will not scale
well.  I guess you have 32*10 of them now, which doesn't bode well as
the number of containers or ports increases.  But that is not the
current problem.

After some reflection, I think that the easiest way to debug this might
be if you are willing to provide a copy of a northbound database that
exhibits the problem (ideally by attaching the DB file rather than some
kind of higher-level dump of it).  Is that OK?  If you do not want to
post it publicly to the mailing list, you can send it to me off-list and
I will keep it confidential.

Thanks,

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

Re: [ovs-discuss] How to find GRE Tunnel ID in OVS ?

[Ben Pfaff]

Please don't drop the mailing list.

I don't understand.  It sounds like you want to extract the tunnel id
and then set the tunnel id to that value.  That doesn't make sense.
What do you actually want to do?

On Thu, Dec 14, 2017 at 08:49:56PM -0500, Vasu S wrote:
> Hi Ben,
> 
> I need to set the tunnel id to the actual id of the GRE tunnel present in
> the topology. That's I need to know a way to extract the tunnel id and set
> that value in the flow indicated earlier.
> 
> -regards
> 
> 
> On Dec 14, 2017 5:27 PM, "Ben Pfaff" <b...@ovn.org> wrote:
> 
> What's wrong with that flow?
> 
> On Thu, Dec 14, 2017 at 05:20:02PM -0500, Vasu S wrote:
> > Thanks Ben,
> >
> > I wanted to know where to find the value for this tun_id for an existing
> > GRE tunnel ?
> > I want to add a flow which looks like :
> >
> > sudo ovs-ofctl -O OpenFlow13 add-flow ovsprx1
> > table=0,in_port=4,dl_dst=52:54:00:78:59:82,dl_type=0x0800,
> nw_dst=10.0.35.12,actions=mod_dl_dst:52:54:00:6c:11:95,
> > set_tunnel:0x0,goto_table:10
> >
> > So, I need to know the tunnel id to set it.
> > Appreciate your help.
> >
> > On Thu, Dec 14, 2017 at 5:06 PM, Ben Pfaff <b...@ovn.org> wrote:
> >
> > > On Thu, Dec 14, 2017 at 04:54:48PM -0500, Vasu S wrote:
> > > > Does any one know any command to find out the GRE tunnel id in OVS.
> > > > I need this to configure flows on OF , but don't know how to extract
> the
> > > > tunnel id.
> > >
> > > OVS calls this the tun_id field.  See ovs-fields(7).
> > >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Is it normal that userspace datapath(without dpdk) have a pool perfermance ?

[Ben Pfaff]

On Fri, Dec 15, 2017 at 02:27:18PM +, Nacht Z wrote:
>  I have install ovs in a server and try to test it’s
>  performance. I found that user space datapath(without dpdk) have
>  a poor performance (6MB/s). The kernel datapath works much
>  better(110M/s). I feel puzzle about this. So can someone tell me
>  is that normal and why this happened?

The userspace interfaces for networking are just slow.  In addition to
other issues, they do extra copies of packets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] How to find GRE Tunnel ID in OVS ?

[Ben Pfaff]

What's wrong with that flow?

On Thu, Dec 14, 2017 at 05:20:02PM -0500, Vasu S wrote:
> Thanks Ben,
> 
> I wanted to know where to find the value for this tun_id for an existing
> GRE tunnel ?
> I want to add a flow which looks like :
> 
> sudo ovs-ofctl -O OpenFlow13 add-flow ovsprx1
> table=0,in_port=4,dl_dst=52:54:00:78:59:82,dl_type=0x0800,nw_dst=10.0.35.12,actions=mod_dl_dst:52:54:00:6c:11:95,
> set_tunnel:0x0,goto_table:10
> 
> So, I need to know the tunnel id to set it.
> Appreciate your help.
> 
> On Thu, Dec 14, 2017 at 5:06 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > On Thu, Dec 14, 2017 at 04:54:48PM -0500, Vasu S wrote:
> > > Does any one know any command to find out the GRE tunnel id in OVS.
> > > I need this to configure flows on OF , but don't know how to extract the
> > > tunnel id.
> >
> > OVS calls this the tun_id field.  See ovs-fields(7).
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] How to find GRE Tunnel ID in OVS ?

[Ben Pfaff]

On Thu, Dec 14, 2017 at 04:54:48PM -0500, Vasu S wrote:
> Does any one know any command to find out the GRE tunnel id in OVS.
> I need this to configure flows on OF , but don't know how to extract the
> tunnel id.

OVS calls this the tun_id field.  See ovs-fields(7).
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Cannot install meter

[Ben Pfaff]

On Thu, Dec 14, 2017 at 04:23:58PM +0100, Cédric MORIN wrote:
> Hi,
> 
> thank you for your reply.
> 
> Actually I didn't need to use dpdk, I just had to set datapath to netdev - as 
> you said.
> 
> However I'm facing another problem now.
> 
> I tried to setup a drop meter with the following command :
> ovs-ofctl -O Openflow13 add-meter s1 meter=1,kbps,bands=type=drop,rate=1000
> I tested it and it worked fine.
> 
> then I tried to setup a dscp-remark meter :
> ovs-ofctl -O Openflow13 add-meter br1 
> meter=1,kbps,band=type=dscp_remark,rate=1000,prec_level=1
> and I got te following error : 
> OFPT_ERROR (OF1.3) (xid=0x2): OFPMMFC_BAD_BAND
> OFPT_METER_MOD (OF1.3) (xid=0x2): ADD meter=1 kbps bands=
> type=dscp_remark rate=1000 prec_level=1
> 
> According to Openflow documentation OFPMMFC_BAD_BAND indicates that the band 
> is unsupported.
> my question is : does OVS 2.8.1 fully implement meter, or just the drop band 
> ? Or is my command incorrect (I successfully tested it with two other type of 
> switches) ?

Current versions of OVS only support "drop" bands.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Issue with OVS Patch port

[Ben Pfaff]

On Wed, Dec 13, 2017 at 09:24:49PM -0500, Vasu S wrote:
> I'm trying to connect two OVS bridges via patch ports, however, as soon as
> I add the ports as type=patch, they disappear from the ifconfig and I'm
> unable to check any traffic hits on either of the patch interfaces. 

Patch ports aren't real interfaces and will not appear in ifconfig.

> Of course, I'm not able to get the ping going with the patched
> interfaces Only one OVS amongst the two is connected to the outside
> network via GRE tunnel.
> 
> Topology roughly looks like as the attached document.
> 
> Problem: Unable to ping VM1 from VM2
> Expected route: VM2->ovsbr-ext->GRE Tunnel->ovsbr1->patchlink->ovsbr2->VM1.
> 
> Patch config on the bridges ovsbr1 and ovsbr2 are as follows:

I suggest tracing the path of a packet.  The FAQ has some suggestions
for how to do this.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.8.1 changes the rates of data packets!

[Ben Pfaff]

It seems like you're just jumping to conclusions here.  What have you
done to understand the situation?

On Fri, Dec 08, 2017 at 05:59:57PM -0800, Dawood Sajjadi wrote:
> when I remove the wireless interfaces from the bridge, there is no problem.
> However, as soon as adding the wireless interfaces to the bridge, the
> problem shows up. So, it seems OVS (at least) is a part of the problem.
> 
> On Fri, Dec 8, 2017 at 5:55 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > On December 8, 2017 5:53:44 PM PST, Dawood Sajjadi <s.d.sajj...@gmail.com>
> > wrote:
> >>
> >> I created a bridge using OVS 2.8.1 in Ubuntu 14.04. The bridge contains 4
> >> physical ports including one ethernet and three wireless ports. The
> >> ethernet port is connected to a laptop that generated dummy traffic using
> >> Iperf. So, the ethernet port is used as the incoming port and the generated
> >> traffic leaves the bridge through the wireless (as the outgoing) ports. I
> >> used tcpdump to capture the traffic at the incoming and outgoing ports of
> >> the bridge and I noticed that the volume of the outgoing traffic (at the
> >> wireless ports) is by far lower than the amount of the incoming traffic
> >> (from the ethernet port). It seems the OVS bridge drops/limits the rate of
> >> outgoing packets. For instance, if the size of the captured traffic using
> >> tcpdump at eth0 is 15 MB, the total size of the captured traffic on
> >> wireless ports is 3 MB!
> >>
> >> I didn't make any change in the default configuration of the OVS. Also,
> >> to ensure that there is no predefined Queue/QoS policy at the bridge, I
> >> used "ovs-vsctl --all destroy qos && ovs-vsctl --all destroy queue"
> >> command. However, the problem persists! Has anyone encountered such an
> >> issue before? I really appreciate having your feedback. Thanks.
> >>
> >
> > OVS doesn't change data rates. You should try to figure out what's going
> > on without making that assumption.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.8.1 changes the rates of data packets!

[Ben Pfaff]

On December 8, 2017 5:53:44 PM PST, Dawood Sajjadi  
wrote:
>I created a bridge using OVS 2.8.1 in Ubuntu 14.04. The bridge contains
>4
>physical ports including one ethernet and three wireless ports. The
>ethernet port is connected to a laptop that generated dummy traffic
>using
>Iperf. So, the ethernet port is used as the incoming port and the
>generated
>traffic leaves the bridge through the wireless (as the outgoing) ports.
>I
>used tcpdump to capture the traffic at the incoming and outgoing ports
>of
>the bridge and I noticed that the volume of the outgoing traffic (at
>the
>wireless ports) is by far lower than the amount of the incoming traffic
>(from the ethernet port). It seems the OVS bridge drops/limits the rate
>of
>outgoing packets. For instance, if the size of the captured traffic
>using
>tcpdump at eth0 is 15 MB, the total size of the captured traffic on
>wireless ports is 3 MB!
>
>I didn't make any change in the default configuration of the OVS. Also,
>to
>ensure that there is no predefined Queue/QoS policy at the bridge, I
>used
>"ovs-vsctl --all destroy qos && ovs-vsctl --all destroy queue" command.
>However, the problem persists! Has anyone encountered such an issue
>before?
>I really appreciate having your feedback. Thanks.

OVS doesn't change data rates. You should try to figure out what's going on 
without making that assumption. ___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Failed assertion in ovs-vswitchd when running OVN

[Ben Pfaff]

Thanks for testing!  I applied this to master.

I don't think it needs backporting, because branch-2.8 doesn't have this
assertion.

On Thu, Dec 07, 2017 at 06:59:40PM -0800, Kevin Lin wrote:
> The patch worked for me! (network works, and no more warnings in ovs-vswitchd)
> 
> > On Dec 7, 2017, at 3:54 PM, Ben Pfaff <b...@ovn.org> wrote:
> > 
> > On Thu, Dec 07, 2017 at 02:44:36PM -0800, Kevin Lin wrote:
> >> Hi Ben,
> >> 
> >> I’ve included the traces for an ARP request, and a ping. ovs-vswitchd also 
> >> logs errors for the return traffic, but I didn’t include that as it seems 
> >> redundant.
> >> 
> >> root@ip-172-31-2-45:/# ovs-appctl ofproto/trace kelda-int 
> >> 'arp,in_port=1,vlan_tci=0x,dl_src=02:00:0a:c5
> >> :34:1e,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.197.52.30,arp_tpa=10.203.4.66,arp_op=1,arp_sha=02:00:0a:c5:34:1e
> >> ,arp_tha=ff:ff:ff:ff:ff:ff'
> >> Flow: 
> >> arp,in_port=1,vlan_tci=0x,dl_src=02:00:0a:c5:34:1e,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.197.52.30,arp_tpa=10.203.4.66,arp_op=1,arp_sha=02:00:0a:c5:34:1e,arp_tha=ff:ff:ff:ff:ff:ff
> >> 
> >> bridge("kelda-int")
> >> ---
> >> 0. in_port=1,dl_src=02:00:0a:c5:34:1e, priority 32768
> >>load:0x2->NXM_NX_REG0[]
> >>resubmit(,1)
> >> 1. arp,dl_dst=ff:ff:ff:ff:ff:ff, priority 1000
> >>LOCAL
> >>output:NXM_NX_REG0[]
> >> -> output port is 2
> >>>>>> Cannot truncate output to patch port <<<<
> > 
> > Thanks for the details.
> > 
> > Would you mind testing this patch?
> >https://patchwork.ozlabs.org/patch/845908/ 
> > <https://patchwork.ozlabs.org/patch/845908/>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Failed assertion in ovs-vswitchd when running OVN

[Ben Pfaff]

On Thu, Dec 07, 2017 at 02:44:36PM -0800, Kevin Lin wrote:
> Hi Ben,
> 
> I’ve included the traces for an ARP request, and a ping. ovs-vswitchd also 
> logs errors for the return traffic, but I didn’t include that as it seems 
> redundant.
> 
> root@ip-172-31-2-45:/# ovs-appctl ofproto/trace kelda-int 
> 'arp,in_port=1,vlan_tci=0x,dl_src=02:00:0a:c5
> :34:1e,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.197.52.30,arp_tpa=10.203.4.66,arp_op=1,arp_sha=02:00:0a:c5:34:1e
> ,arp_tha=ff:ff:ff:ff:ff:ff'
> Flow: 
> arp,in_port=1,vlan_tci=0x,dl_src=02:00:0a:c5:34:1e,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.197.52.30,arp_tpa=10.203.4.66,arp_op=1,arp_sha=02:00:0a:c5:34:1e,arp_tha=ff:ff:ff:ff:ff:ff
> 
> bridge("kelda-int")
> ---
>  0. in_port=1,dl_src=02:00:0a:c5:34:1e, priority 32768
> load:0x2->NXM_NX_REG0[]
> resubmit(,1)
>  1. arp,dl_dst=ff:ff:ff:ff:ff:ff, priority 1000
> LOCAL
> output:NXM_NX_REG0[]
>  -> output port is 2
>   Cannot truncate output to patch port 

Thanks for the details.

Would you mind testing this patch?
https://patchwork.ozlabs.org/patch/845908/
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] (no subject)

[Ben Pfaff]

On Thu, Dec 07, 2017 at 11:39:23AM +0530, shivani dommeti wrote:
> I am using OVS version 2.8.2
> I have a problem when executing "insert-buckets".I created a group of
> type select and when i try to insert a bucket using "insert-bucket"
> command supported by OpenFlow1.5 the group type gets changed from
> "select" to "all" (type=select -> type=all). Can I keep group's
> properties such as type, selection_method, fields when inserting new
> buckets?

Thank you for the bug report.  I sent out a fix:
https://patchwork.ozlabs.org/patch/845887/
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Failed assertion in ovs-vswitchd when running OVN

[Ben Pfaff]

On Thu, Dec 07, 2017 at 09:26:14AM -0800, Kevin Lin wrote:
> Hi,
> 
> I work on Kelda (kelda.io ) with Ethan Jackson. We run a 
> containerized, distributed version of OVN. The master branch of 
> openvswitch/ovs (commit 07754b23ee5027508d64804d445e617b017cc2d1) fails with 
> the following assertion in ovs-vswitchd:
> 
> ovs-vswitchd(handler2): ofproto/ofproto-dpif-xlate.c:3704: assertion 
> !truncate failed in compose_output_action__()
> 
> whenever we try to use the OVN network. A little background on our setup:
> We’re a container orchestrator that uses OVN for the container network.
> One machine in our cluster runs ovn-northd and ovsdb-server. The network is 
> mostly configured from here (creating the logical ports, creating ACLs etc).
> Another machine runs ovn-controller, ovs-vswitchd, and ovsdb-server. We 
> install some container-specific OpenFlow rules by connecting directly to 
> ovs-vswitchd, and of course ovs-vswitchd also receives rules from OVN.
> ovs-vswitchd does not crash immediately after the rules are installed. But it 
> crashes as soon as the network is used (e.g. a ping from one container to 
> another).
> 
> The commit before the commit that introduced the assertion works for us 
> (https://github.com/openvswitch/ovs/commit/48f704f4768d13f85252bac4f93c8d45d8ab3eea
>  
> ).
> 
> I’ve attached the ovs-vswitchd logs. I’m not sure how helpful the output of 
> ovs-bugtool will be given our containerized setup, but I’ve also attached the 
> output of running that from within the ovs-vswitchd container from before and 
> after the crash. Note, because the ovs-vswitchd container crashed, the 
> “after” tarball was generated after restarting the container, so I’m not sure 
> if any of the commands it ran actually succeeded.
> 
> The crash is trivial for me to reproduce, so please let me know if there’s 
> anymore information I can give you.

Thank you for the report.

I don't see a good reason that this should be a condition that kills
ovs-vswitchd.  I think that it will be both easier to debug and less
inherently harmful if we change it to an error message.  I sent out a
patch that does that:
https://patchwork.ozlabs.org/patch/845845/

It would be great if you could apply the patch and then try to track
down the activity that triggers the error.  "ofproto/trace" is the best
way to do that, if you can find the right packet or flow, because it
will give us all the details on how the problem gets triggered.

Thanks,

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

Re: [ovs-discuss] OVSDB connection keep-alive vs. echo RPC

[Ben Pfaff]

On Thu, Dec 07, 2017 at 01:59:45PM -0500, Matt Layher via discuss wrote:
> But that leads me to another question: does ovsdb-server send echo RPCs to
> its clients at all?  If so, I can implement something to reply in my receive
> loop.  If not, I won't bother.

Yes, it does (unless configured not to do that).
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVSDB connection keep-alive vs. echo RPC

[Ben Pfaff]

On Thu, Dec 07, 2017 at 12:24:51PM -0500, Matt Layher via discuss wrote:
> I'm working on implementing an OVSDB client in Go
> (https://godoc.org/github.com/digitalocean/go-openvswitch/ovsdb) and
> recently implemented the Echo RPC.
> 
> https://tools.ietf.org/html/rfc7047#section-4.1.11
> 
> According to the RFC, the purpose of Echo is "to verify the liveness of a
> database connection".  Does this mean that Echo should be used as a
> keep-alive of sorts for long-running connections?  I'm thinking about adding
> a background loop to my client that sends Echo RPCs at a regular interval
> for this purpose.

Yes, echo requests can be used for this purpose and that's their normal
use.

The C and Python libraries suppress this functionality by default when
they connect over a unix domain socket, because the kernel reliably
ensures that unix domain sockets stay connected.

> Next, if I were to connect to ovsdb-server via TCP instead of UNIX socket,
> would enabling TCP keep-alives serve the same purpose?

I believe that TCP keepalives only affect otherwise idle connections.
TCP keepalives normally operate very slowly, on the order of several
minutes to hours.  I also understand that they are not necessarily
end-to-end if the connection passes through some kinds of proxies etc.


> If neither of these approaches are necessary, it'd avoid adding some
> additional complexity to the code.  I'd be very curious to hear what folks
> have done.

The kernel does monitor TCP connections that have outstanding data to
make sure that they are still operational, but it takes minutes (up to
20 minutes in some situation if I recall correctly) to detect and
disconnect in that case.  We have found that echo requests and replies
are valuable in situations where we just can't wait that long.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs_assert(classifier_is_empty(>cls)) failed when restart openvswitch service.

[Ben Pfaff]

On Wed, Dec 06, 2017 at 08:28:30PM +, Zhanghaibo (Euler) wrote:
> Hello all,
> 
> I run into abort issue when restart openvswitch service, the coredump file 
> shows that ovs_assert() failed in function oftable_destroy()/ofproto.c.
> 
> The problem is pretty hard to reproduce, Do you have any idea about this? OVS 
> release is v2.7.0, Any suggestion would be appreciated.
> 
> Source codes and gdb information were copied below.

I'd first recommend upgrading to the latest on the 2.7 branch, which has
over 230 bug fixes since 2.7.0 was released.
___
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]

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
> Megaflow: 
> recirc_id=0,eth,ip,in_port=32770,nw_dst=192.168.128.0/24,nw_frag=no
> Datapath actions: drop
> This flow is handled by the userspace slow path because it:
> - Sends "packet-in" messages to the OpenFlow controller.
> 
> Clearly that's a bug.  I'll see what I can do about it.
> 
> > Also, Whoever improved the output of ofproto/trace thanks a ton!
> 
> That was me :-)  You're welcome.
> 
> 
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Ben Pfaff]

For packets that go to the slow path, the trace is supposed to show what
happens when the packet is processed in the slow path and then note why
it goes to the slow path.  That wasn't happening in your case because of
that formatting/parsing mismatch.

On Wed, Dec 06, 2017 at 06:38:23AM +, Amar Padmanabhan wrote:
> oh, I think I remember that output to slow_path doesn’t show up in the 
> ofproto/trace. Don’t remember why though
> - Amar
> 
> From: <ovs-discuss-boun...@openvswitch.org> on behalf of Amar Padmanabhan 
> <amarpadmanab...@fb.com>
> Date: Tuesday, December 5, 2017 at 9:59 PM
> To: "ovs-discuss@openvswitch.org" <ovs-discuss@openvswitch.org>, Ben Pfaff 
> <b...@ovn.org>
> Cc: Jacky Tian <xjt...@fb.com>
> Subject: [Potential Spoof] [ovs-discuss] Discrepancy between ofproto/trace 
> output and dpctl dump-flows output
> 
> Hi,
> 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))
> 
> 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
> 
> 4 - Misc info:
> ovs-vsctl (Open vSwitch) 2.8.0
> DB Schema 7.15.0
> 
> ovs-appctl dpif/show
> gtp_br0:
> gtp0 32768/4: (gtp: key=flow, remote_ip=flow)
> gtp_br0 65534/1: (internal)
> int_nat_peer 32770/3: (system)
> veth0_ovs 32769/2: (system)
> 
> Also, Whoever improved the output of ofproto/trace thanks a ton!
> 
> Thanks in advance!
> Amar
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] L2 messages with proprietary ethertype dropped

[Ben Pfaff]

On Tue, Dec 05, 2017 at 07:24:10PM -0500, Raghavendra Hegde wrote:
> I am using a 3rd party application that runs on two VMs and uses L2
> messages for health checking between the VMs. The L2 messages use a
> proprietary ethertype (0x8e9f) for messaging. I see the L2 message going
> out of the VM. However, I don’t see the messages going out of the host. I
> disabled port security on the neutron port, and the L2 messages go through
> fine. All the L3 message between the two VMs go through fine even with
> port- security enabled. My guess is that OVS is dropping the L2 messages.
> Is it possible that OVS is dropping the L2 messages because it doesn’t
> understand the new ethertype? Do we have to add any new flows to the OVS
> tables to allow the proprietary ethertype L2 messages?

OVS does not drop proprietary Ethertypes by default, but the flow table
that Neutron installs might.  You can use "ofproto/trace" to find out
what's happening.  See ovs-vswitchd(8) for more information.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Ben Pfaff]

On Mon, Dec 04, 2017 at 07:42:06PM +0530, Pradeep K.S wrote:
> I have a created bond interface, with multiple slaves. I want to program
> flows
> such that packets arriving on port X -> should be directed to bond port
> But the
> problem is bond port doesn't have ofportid, how to program such a flow
> using ovs-ofctl
> 
> I tried setting bond_fake_iface, still I don't get  ofportid to program
> ovs-ofctl flows.

I don't think this is currently possible.  The FAQ says:

Q: It looks like each of the interfaces in my bonded port shows up as an
individual OpenFlow port.  Is that right?

A: Yes, Open vSwitch makes individual bond interfaces visible as OpenFlow
ports, rather than the bond as a whole.  The interfaces are treated
together as a bond for only a few purposes:

- Sending a packet to the OFPP_NORMAL port.  (When an OpenFlow controller
  is not configured, this happens implicitly to every packet.)

- Mirrors configured for output to a bonded port.

It would make a lot of sense for Open vSwitch to present a bond as a single
OpenFlow port.  If you want to contribute an implementation of such a
feature, please bring it up on the Open vSwitch development mailing list at
d...@openvswitch.org.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS Patch Ports

[Ben Pfaff]

On Fri, Dec 01, 2017 at 11:57:22AM -0500, Fouad Hallal wrote:
> I have tested OVS patch ports functionality in a simple 3 bridges network
> by using Mininet custom topology.  I configured macro flows by cross
> connecting the different bridge ports.  Packets passed between the
> different bridges and I was able to confirm by inspecting OVS flows
> counters.
> 
> I have been looking for documentation about OVS implementation of patch
> ports.  Specifically, I need to learn about the metadata that is passed
> between the different bridges as packets proceed from one bridge to
> another.  Is their a data structure (other than the skb) that is passed
> along?  Are the input ports and output ports values, that a given packet
> traversed for different bridges, kept around through the life of the
> packet?  Any pointers are much appreciated.

Traversing a patch port is supposed to be analogous to traversing a
veth.  The same fields should be preserved.  This is similar to
traversing a physical Ethernet cable from port to port, except that one
or two metadata fields should be preserved; skb_priority is the one that
comes to mind.

The input port isn't preserved; it changes to the patch port.

Output port isn't usually a field.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] clarification on sflow documentation

[Ben Pfaff]

On Wed, Nov 29, 2017 at 05:45:11PM -0800, Shivaram Mysore wrote:
> Hello,
> I am referring to http://docs.openvswitch.org/en/latest/howto/sflow/
> 
> $ ovs-vsctl -- --id=@sflow create sflow agent=${AGENT_IP} \
> target="${COLLECTOR_IP}:${COLLECTOR_PORT}" header=${HEADER_BYTES} \
> sampling=${SAMPLING_N} polling=${POLLING_SECS} \
>   -- set bridge br0 sflow=@sflow
> 
> In the above, the quotes need to be escaped otherwise, the command will not
> work.  I think it should be fixed to:
> 
> $ ovs-vsctl -- --id=@sflow create sflow agent=${AGENT_IP} \
> target=*\*"${COLLECTOR_IP}:${COLLECTOR_PORT}*\*" header=${HEADER_BYTES} \
> sampling=${SAMPLING_N} polling=${POLLING_SECS} \
>   -- set bridge br0 sflow=@sflow

Thanks for the report.  I sent out a patch for review:
https://patchwork.ozlabs.org/patch/843145/
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Tx/Rx count not increasing OVS-DPDK

[Ben Pfaff]

On Wed, Nov 29, 2017 at 10:57:12AM +0530, abhishek jain wrote:
> I'm having 2 VMs running with ovs-dpdk as a networking agent on
> openstack compute node.
> When I'm checking the external connectivity of the VMs by pinging to
> the external world,the Tx/Rx count of the VMs is not increasing.
> 
> 
> However I'm able to ping the local-Ip of the respective Vms.
> Let me know the possible solution for this.

I don't know why you're writing to me specifically here.  I am not an
expert on OVS-DPDK or on OpenStack.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] How to set QoS for VM egress traffic on tunnel mode

[Ben Pfaff]

On Wed, Nov 22, 2017 at 09:50:54AM +, 王志克 wrote:
> Hi All,
> 
> I want to set QoS with guide from below link “egress traffic shaping”, but do 
> not know how for tunnel mode.
> http://docs.openvswitch.org/en/latest/faq/qos/
> 
> My scenario:
> 
> I have several VM ports, and several VxLan ports in br0, and there is one 
> seprate eth0 port (not in br0), which is the underlay port of Vxlan port.
> Currently I add rule to match VM traffic to certain Vxlan port, and all these 
> vxlan ports would go out through eth0.
> 
> Now I want to enable egress traffic shaping, eg:
> VM1 goes out with min_rate=10M, max_rate=100M.
> VM2 goes out with min_rate=50M, max_rate=200M.
> 
> In the given example in http://docs.openvswitch.org/en/latest/faq/qos/ 
> chapter “egress traffic shaping”, it directly uses the physical port. But in 
> tunnel case, I can NOT specify the physical port directly.
> So how to configrue egress traffic shaping in tunnel case? Appreciate some 
> example configruation. Thanks.

You would want to configure shaping on the physical output port in this
case.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Idea of an ovn native "rally"

[Ben Pfaff]

On Thu, Nov 23, 2017 at 12:01:33PM +0100, Miguel Angel Ajo Pelayo wrote:
> Today during coffee I was discussing with Jakub the idea of having
> some sort of "rally" [1] [2] like project to measure the native reponse
> of OVN at scale, measuring things like:
> 
>   * NB object creation to SB update
>   * Tap creation to SB port binding, and to connectivity.
>   * dnat NAT association to dnat connectivity
> 
>   * any other ideas?
> 
> 
> This project has been specially helpful (in OpenStack) to detect race
> conditions and bottlenecks. But I'm afraid that the OpenStack overhead
> hide the real OVN numbers.

I support adding some OVN testing, especially scale testing.  There is a
dormant ovn scale testing project that might be a place to start (I've
never looked at it personally):
https://github.com/openvswitch/ovn-scale-test
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] 回复： ovs-dpctl problem

[Ben Pfaff]

How did that flow get added?  I don't think that OVS datapaths support
wildcarding eth_type.

On Thu, Nov 23, 2017 at 05:55:35PM +0800, 焦利涛 wrote:
> Hi all:
> how does the match with flow table work?   
>such as:
>   #ovs-dpctl dump-flows
>   # in_port(2),eth_type(0/0x), packets:0, bytes:0, used:never, actions:3
> 
>  if there is a package from port 2, but it doesn't go to port 3.
>   why does it not work?
> 
> -- 原始邮件 --
> 发件人: "Aaron Conole";<acon...@redhat.com>;
> 发送时间: 2017年11月14日(星期二) 凌晨0:48
> 收件人: "Ben Pfaff"<b...@ovn.org>;
> 抄送: "焦利涛"<309569...@qq.com>; "bugs"<b...@openvswitch.org>; 
> 主题: Re: [ovs-discuss] ovs-dpctl problem
> 
> 
> 
> Ben Pfaff <b...@ovn.org> writes:
> 
> > On Mon, Nov 13, 2017 at 11:21:38AM -0500, Aaron Conole wrote:
> >> "焦利涛" <309569...@qq.com> writes:
> >> 
> >> > Hi ：
> >> >  I have a problem that when i use the ovs-dpctl to add a flow into 
> >> > datapath, it occurs "ovs-dpctl:
> >> > parsing flow key (Invalid argument)"
> >> >
> >> > example:
> >> >root@jlt:~# ovs-dpctl add-flow system@myDP 
> >> > "in_port(1),eth_type(0x800),ipv4
> >> > (src=172.31.110.4,dst=172.31.110.5)" 2
> >> > ovs-dpctl: parsing flow key (Invalid argument)
> >> 
> >> You may be able to use 'dmesg' to see which key is missing.
> >
> > I believe that this particular error comes from the userspace parser,
> > not the kernel.
> 
> Seems you're correct.
> 
> Even more, using the supplied command:
> 
> 11:45:39 aconole {master} ~/git/ovs/lib$ sudo ovs-dpctl add-flow myDP 
> "in_port(1),eth_type(0x800),ipv4(src=172.31.110.4,dst=172.31.110.5)" 2
> 11:45:57 aconole {master} ~/git/ovs/lib$ sudo ovs-dpctl dump-flows
> in_port(1),eth_type(0x0800),ipv4(src=172.31.110.4,dst=172.31.110.5), 
> packets:0, bytes:0, used:never, actions:2
> 
> Maybe there's an issue with whatever OvS version is being used (although
> I don't know of any such issues).
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS 2.8.0

[Ben Pfaff]

On Tue, Nov 21, 2017 at 12:08:51PM -0200, Marcos Felipe Schwarz wrote:
> Hi,
> 
> The current solution for running OVS with non-root user in Fedora makes it 
> not possible to support UIO drivers [1].
> Setting the user to root:root via /etc/sysconfig/openvswitch should be a 
> solution, but it is also currently broken, since the systemd 
> ovs-vswitchd.service is forcing the group :hugetlbfs to /dev/hugepages [2], 
> which breaks root access to it.
> Would it be possible to change the permissions only if the user in not root? 
> Currently I can only make UIO work on fedora removing this hardcoded 
> permissions on the systemd files. I believe that either root:root should not 
> conflict with the systemd script or be explicitly unsupported.
> 
> [1] For Linux kernel 4.0 and newer, the ability to obtain physical page frame 
> numbers for unprivileged users from /proc/self/pagemap was removed.
> Source. 
> http://dpdk.org/browse/dpdk/commit/?id=cdc242f260e766bd95a658b5e0686a62ec04f5b0
> [2] ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages. 
> https://github.com/openvswitch/ovs/blob/master/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in

Are you able to submit a patch to solve the problem?  It sounds like you
have a specific idea about what should be done.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs 2.8 with ocata devstack environment

[Ben Pfaff]

On Mon, Nov 27, 2017 at 09:43:19AM +0530, Sailas Babu wrote:
> I am trying to spawn VMs using ocata devstack  with ovs 2.8 version.
> wanted to check few specific (  mpls o gre) patches that are only available
> in ovs 2.8 .
> 
> ocata inherently using 2.6 version , which i stopped manaully and ovs
> version upgraded to ovs 2.8 .  i am facing few problems
> 1. if i install ovs 2.8 as root ,  when i run stack.sh  as stack user (
> stack user has given sudo permissions rights ) , the bridges it try to
> access ( br-int , br -ex ) are not accessible ( though br-int , br-ex
> exists )  and devstack getting timed at waiting for br-int to be available.

I guess that OpenStack needs to use "sudo" to run ovs-ofctl and
ovs-vsctl.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] What is a l2 pkt microflow

[Ben Pfaff]

On November 20, 2017 11:44:09 PM PST, Sara Gittlin <sara.gitt...@gmail.com> 
wrote:
>Thank you Ben
>Is this L2 flow is an entry in one of the kernel megaflow tables ?
>otherwise if it an entry in the kernel microflow table - then there
>should be  multiple microflow tables,  because L2 flow keys consist
>only of L2 header, while  for other flow the keys are l2+l3 headers. i
>thought that there is only a single microflow table so  classification
>takes  O(1).
>--Sara
>
>
>On Mon, Nov 20, 2017 at 7:38 PM, Ben Pfaff <b...@ovn.org> wrote:
>> On Thu, Nov 16, 2017 at 07:46:05PM +0200, Sara Gittlin wrote:
>>> I understand that microflow kernel cache entries consist of full set
>of
>>> header keys.
>>> What about a l2 pkt e.g cfm pkt. What are the hash keys for cfm pkt
>in the
>>> single microflow table?
>>
>> Just the Ethernet header.

There is one microflow table. Like many hash tables, it has a variable length 
key.___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenFlow “select” group

[Ben Pfaff]

No.

On Mon, Nov 20, 2017 at 11:41:26AM -0600, Prabhu wrote:
> Just curios to know, does Group selection method support weighted round
> robin selection method ?
> 
> 
> On 11/20/2017 11:37 AM, Ben Pfaff wrote:
> >On Thu, Nov 16, 2017 at 04:41:07PM -0500, Ronaldo Resende wrote:
> >>I know that Open vSwitch 2.4 and later + OpenFlow 1.4, by default, hashes
> >>some headers fields to choose a bucket in a select group.
> >>
> >>What if I want to change the way this is being done? What would be the
> >>right approach to accomplish this? (i.e distribute packets among buckets
> >>using some king of counter, to create an evenly load balance).
> >>
> >>Which codes should I considering poking around?
> >You would need to start by figuring out how to implement this at the
> >datapath level, that is, in the Linux kernel module.  The datapath
> >doesn't currently have any concept that can be used to serialize
> >packets.  (Serializing packets will slow things down because it
> >inherently prevents parallelism, but maybe you don't care about
> >performance?)  Maybe you could add some kind of datapath action to
> >increment a counter and store it in dp_hash and then recirculate,
> >analogous to the way that there's an action to hash fields and
> >recirculate.
> >___
> >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] What is a l2 pkt microflow

[Ben Pfaff]

On Thu, Nov 16, 2017 at 07:46:05PM +0200, Sara Gittlin wrote:
> I understand that microflow kernel cache entries consist of full set of
> header keys.
> What about a l2 pkt e.g cfm pkt. What are the hash keys for cfm pkt in the
> single microflow table?

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

Re: [ovs-discuss] OpenFlow “select” group

[Ben Pfaff]

On Thu, Nov 16, 2017 at 04:41:07PM -0500, Ronaldo Resende wrote:
> I know that Open vSwitch 2.4 and later + OpenFlow 1.4, by default, hashes
> some headers fields to choose a bucket in a select group.
> 
> What if I want to change the way this is being done? What would be the
> right approach to accomplish this? (i.e distribute packets among buckets
> using some king of counter, to create an evenly load balance).
> 
> Which codes should I considering poking around?

You would need to start by figuring out how to implement this at the
datapath level, that is, in the Linux kernel module.  The datapath
doesn't currently have any concept that can be used to serialize
packets.  (Serializing packets will slow things down because it
inherently prevents parallelism, but maybe you don't care about
performance?)  Maybe you could add some kind of datapath action to
increment a counter and store it in dp_hash and then recirculate,
analogous to the way that there's an action to hash fields and
recirculate.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] in_port=local never matches for flows

[Ben Pfaff]

On Fri, Nov 17, 2017 at 02:16:55PM +, Jan De Landtsheer wrote:
> Hello again,
> 
> I'm trying to define a conntrack flow that allows connections from linux
> namespace1 to a test namespace, and block everything from the test
> namespace to the host
> 
> for that I create a bridge, add a port, send the port into the namespace,
> give it an IP. on the host I add an IP ont the local interface of the
> bridge:
> 
> ```
> ovs-vsctl add-br test
> ovs-vsctl add-port test tst -- set Interface test type=internal

That's a curious set of commands.  Is 'tst' in the second line a typo?
Is "test" in the "set Interface" command a typo?

And then, later on, when you match on "local", do you expect that to
match on your "tst" interface or on the built-in "test" interface?  It
is the latter that it will match.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Source Code - Multiple Controllers Round Robin Load Balancing

[Ben Pfaff]

It seems to me like a bad idea, in general, to use round robin load
balancing to send packets to controllers because that is likely to
reorder packets.  I think that it would probably be a better idea to
balance packets across controllers on a flow-by-flow basis.  I think
that you could use an OpenFlow "select" group for that, by using a
bucket for each controller.  That would not require any change to OVS.

On Sun, Nov 19, 2017 at 01:47:01PM -0800, Brian Perry wrote:
> Summary: OvS last commit 52f793b
> I am trying to modify the switch's code to use a round robin scheduler for
> sending asynchronous messages (especially PACKET_IN messages) to one of the
> controllers within a multiple controller SDN setup. After traversing the
> code I think I found where I need to insert this round robin scheduler,
> line 4766 and 6225 of ofproto-dpif-xlate.c.
> 
> I plan on modifying this part of the code and testing it to see if I was
> correct but it would be great to have some feedback from the community on
> this.
> 1) Am I on the right path, do I only need to modify the code around line
> 4766? Or do I need to modify another part of the code?
> 2) What is OFPACT_CONTROLLER case for? From what I can gather macro
> OFPACT_FOR_EACH uses a macro that goes through a list that deal with table
> entry actions but it could call the execute_controller_action() function
> and I don't know why it would.
> 3) What does emit_continuation() function do? It looked like it had to do
> with table lookups instead of sending asynchronous messages to the
> controller. If it only does table lookups why would it call the
> execute_controller_action() function.
> 
> 
> Details:
> I setup a simple Mininet topology with a single switch, 3 user computers,
> and 2 controllers, where everything is connected to the switch. Currently
> when the switch receives a packet with no corresponding forwarding rule it
> sends a request to both controllers. I would like it so that it sends the
> forwarding rule request in a round robin method. So the first forwarding
> rule request will be sent to only controller 1, then the next forwarding
> rule request will be sent to only controller 2, then the next one to only
> controller 1, then the next one only to controller 2, etc.
> 
> Along side other documents I've read a description of the Open vSwitch
> architecture (https://www.slideshare.net/rajdeep/openvswitch-deep-dive) and
> pages 25-28 of Pavel's master thesis (https://mail.openvswitch.org/
> pipermail/ovs-discuss/2017-February/043763.html) to get a better
> understanding of the internals of OvS. This information paired with the
> following post (https://mail.openvswitch.org/pipermail/ovs-discuss/2016-
> March/040236.html) informed me that the source code I am looking for is
> used within the Userspace and located within the ofproto directory. I
> started looking in the ofproto directory for the handle_openflow()
> function. This eventually lead me to look at the structure and usage of
> ofconn which lead me to line 1741 of connmgr.c where I found the structure
> ofproto_async_msg and function connmgr_send_async_msg. After following the
> function I noticed that ofproto_async_msg.controller_id is assigned in only
> 2 different places; within the execute_controller_action() and
> emit_continuation() functions. I continued following the
> execute_controller_action() function and noticed that it's called in only 5
> different locations all within the file ofproto-dpif-xlate.c. Within those
> 5 locations only lines 4766 and 6225 use some sort of loop to craft and
> send asynchronous messages to multiple controllers.
> 
> So my questions become:
> 1) Am I on the right path, do I only need to modify the code around line
> 4766? Or do I need to modify another part of the code?
> 2) What is OFPACT_CONTROLLER case for? From what I can gather macro
> OFPACT_FOR_EACH uses a macro that goes through a list that deal with table
> entry actions but it could call the execute_controller_action() function
> and I don't know why it would.
> 3) What does emit_continuation() function do? It looked like it had to do
> with table lookups instead of sending asynchronous messages to the
> controller. If it only does table lookups why would it call the
> execute_controller_action() function.

> ___
> 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] Help adding ports in ovs-sandbox

[Ben Pfaff]

ovs-vswitchd running in the sandbox doesn't interact with the system at
all, so ports you create there won't appear when you run system
utilities.

On Tue, Nov 14, 2017 at 07:29:16PM +, Omar Ramadan wrote:
> Hello,
> 
> 
> I am using the ovs-sandbox to run ovs-vswitchd in gdb and am having some 
> trouble adding ports to a bridge I've created. The port is added to the 
> bridge, however the link state is down and neither the bridge nor the added 
> port appear in the list of system interfaces. Therefore, it isn't able to 
> process any traffic.
> 
> 
> root@magma-dev:/home/vagrant/ovs/tutorial# ovs-vsctl -V
> 
> ovs-vsctl (Open vSwitch) 2.8.0
> 
> DB Schema 7.15.0
> 
> root@magma-dev:/home/vagrant/ovs/tutorial# uname -a
> Linux magma-dev 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 
> GNU/Linux
> 
> 
> root@magma-dev:/home/vagrant/ovs/tutorial# ovs-vsctl add-port gtp_br0 gtp0 -- 
> set interface gtp0 ofport_request=32768 type=gtp option:remote_ip=flow 
> options:key=flow
> 
> 
> root@magma-dev:/home/vagrant/ovs/tutorial# ovs-ofctl show gtp_br0
> 
> OFPT_FEATURES_REPLY (xid=0x2): dpid:cedec4698b43
> 
> n_tables:254, n_buffers:0
> 
> 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
> 
>  32768(gtp0): addr:aa:55:aa:55:00:1b
> 
>  config: PORT_DOWN
> 
>  state:  LINK_DOWN
> 
>  speed: 0 Mbps now, 0 Mbps max
> 
>  LOCAL(gtp_br0): addr:ce:de:c4:69:8b:43
> 
>  config: PORT_DOWN
> 
>  state:  LINK_DOWN
> 
>  speed: 0 Mbps now, 0 Mbps max
> 
> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
> 
> 
> root@magma-dev:/home/vagrant/ovs/tutorial# ip a
> 
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
> default qlen 1
> 
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 
> inet 127.0.0.1/8 scope host lo
> 
>valid_lft forever preferred_lft forever
> 
> inet6 ::1/128 scope host
> 
>valid_lft forever preferred_lft forever
> 
> 2: eth0:  mtu 1500 qdisc pfifo_fast master 
> unmanaged_br0 state UP group default qlen 1000
> 
> link/ether 08:00:27:06:49:4f brd ff:ff:ff:ff:ff:ff
> 
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> group default qlen 1000
> 
> link/ether 08:00:27:f4:93:02 brd ff:ff:ff:ff:ff:ff
> 
> inet 192.168.60.142/24 brd 192.168.60.255 scope global eth1
> 
>valid_lft forever preferred_lft forever
> 
> inet6 fe80::a00:27ff:fef4:9302/64 scope link
> 
>valid_lft forever preferred_lft forever
> 
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> group default qlen 1000
> 
> link/ether 08:00:27:67:d7:c8 brd ff:ff:ff:ff:ff:ff
> 
> inet 42.42.42.1/24 brd 42.42.42.255 scope global eth2
> 
>valid_lft forever preferred_lft forever
> 
> inet6 fe80::a00:27ff:fe67:d7c8/64 scope link
> 
>valid_lft forever preferred_lft forever
> 
> 5: veth0_ovs@veth0:  mtu 1500 qdisc noqueue 
> state UP group default qlen 1000
> 
> link/ether a6:0a:c5:a6:f6:d9 brd ff:ff:ff:ff:ff:ff
> 
> inet6 fe80::a40a:c5ff:fea6:f6d9/64 scope link
> 
>valid_lft forever preferred_lft forever
> 
> 6: veth0@veth0_ovs:  mtu 1500 qdisc noqueue 
> master unmanaged_br0 state UP group default qlen 1000
> 
> link/ether 0e:62:49:8c:e8:c6 brd ff:ff:ff:ff:ff:ff
> 
> 7: unmanaged_br0:  mtu 1500 qdisc noqueue 
> state UP group default qlen 1000
> 
> link/ether 08:00:27:06:49:4f brd ff:ff:ff:ff:ff:ff
> 
> inet 10.0.2.15/24 brd 10.0.2.255 scope global unmanaged_br0
> 
>valid_lft forever preferred_lft forever
> 
> inet6 fe80::a00:27ff:fe06:494f/64 scope link
> 
>valid_lft forever preferred_lft forever
> 
> Thanks for the help,
> Omar
> 
> 
> 
> 
> 
> 

> ___
> 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] Can't add a row into a table with ovsdb-client

[Ben Pfaff]

On Tue, Nov 14, 2017 at 02:40:22PM -0500, Scott Reeve wrote:
> Tried a whole bunch of things but none seem to work.
> There is one db: "hardware_vtep"
> One of the tables is Ucast_Macs_Local:
> 
> 
> "Ucast_Macs_Local": {
>   "columns": {
> "MAC": {
>   "type": "string"},
> "ipaddr": {
>   "type": "string"},
> "locator": {
>   "type": {
> "key": {
>   "refTable": "Physical_Locator",
>   "type": "uuid"}}},
> "logical_switch": {
>   "type": {
> "key": {
>   "refTable": "Logical_Switch",
>   "type": "uuid",
>   "isRoot": true},
> 
> I want to add one row into this table.
> Does "key" being present mean that the key is required?  Are there two keys
> for Ucast_Macs_Local?
> 
> Here's an example of what I've tried:
> sudo ovsdb-client transact tcp:10.100.52.92:6640 '["hardware_vtep",
> {"op":"insert", "table":"Ucast_Macs_Local",
> "row":{"Logical_Switch":"889240b8-13df-42cb-a733-18efe90aaf72"}}]'
> 
> The syntax of the schema has me quite confused.
> 
> Any suggestions are greatly appreciated.

Did you read RFC 7047?  It explains the schema syntax and the
transaction syntax.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Multiple Goto on Single Flow Statement

[Ben Pfaff]

On Tue, Nov 14, 2017 at 07:14:13PM +, Michael Williams wrote:
> Under OvS 2.4.1 when we issue the following command;
> 
> sudo ovs-ofctl -O OpenFlow13 add-flow s1 
> table=0,in_port=2,actions=goto_table:1,goto_table:2
> 
> 
> we get this message;
> 
> ovs-ofctl: instruction goto_table may be specified only once
> 
> 
> Does OvS support this in later versions?

No, OpenFlow forbids multiple goto_table instructions in an action list.

You can use the OVS extension "resubmit" action for the same purpose.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] jsonrpc

[Ben Pfaff]

For the unsuccessful case, did you check the database log?  It may
contain a log message pointing to the mistake.

On Mon, Nov 13, 2017 at 07:26:48PM -0300, Edison Albuquerque wrote:
> Thank you Ben.
> There's a lot of information.
> I'll have to dissect it.
> I tried this before:
> 
> "
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
> 
> import socket
> import json
> 
> OVSDB_IP = '127.0.0.1'
> OVSDB_PORT = 6640
> 
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect((OVSDB_IP, OVSDB_PORT))
> 
> # INSERT NA INTERFACE TABLE, PORT TABLE e BRIDGE TABLE
> list_dbs_query = {"method":"transact", "params": ["Open_vSwitch",
> {"uuid-name": "if3d", "op": "insert", "row": {"name": "s1-eth3", "type":
> "system"}, "table": "Interface"},
> {"uuid-name": "port3d", "op": "insert", "row": {"name": "s1-eth3",
> "interfaces": ["named-uuid", "if3d"]}, "table": "Port"},
> {"op":"insert","row":{"ports":["named-uuid","port3d"],"name":"s1"},"table":"Bridge"},
> 
> {"op":"mutate","table":"Open_vSwitch","where":[],"mutations":[["next_cfg","+=",1]]},{"op":"commit","durable":True}],"id":0}
> 
> 
> s.send(json.dumps(list_dbs_query))
> response = s.recv(4000)
> print response
> "
> I receive a response. But when I run Select no interface has been added.
> I'm sure this time it will work.
> 
> 2017-11-13 19:00 GMT-03:00 Ben Pfaff <b...@ovn.org>:
> 
> > On Mon, Nov 13, 2017 at 06:47:05PM -0300, Edison Albuquerque wrote:
> > > Sorry if this has been asked before.
> > > There's few examples on how to use jsonrpc to insert an interface, for
> > > example.
> > > For us, newbies, examples are extremely valuable, more than a thousand
> > > words.
> > > If some kind soul has an example on how to insert a new interface
> > (s1-eth3)
> > > in a single switch (s1) with two interfaces (s1-eth2 and s1-eth3) please
> > > share with me.
> > > That would be a complete example, including Port and Bridge
> > atualizations.
> >
> > If you run something like this:
> > ovs-vsctl -vjsonrpc -- add-bond s1 s1-eth3 s1-eth2 s1-eth3
> > then you will see what ovs-vsctl does to insert such a bond, logged as
> > the jsonrpc module.
> >
> 
> 
> 
> -- 
> 
> *He ain't heavy. He's my brother.*
> 
> Prof. Edison de Queiroz Albuquerque, BSc, Msc, Dr.
> Adjunto da Escola Politécnica de Pernambuco, Universidade de Pernambuco
> (POLI/UPE)
> Professor do Curso de Engenharia de Computação
> Líder do Grupo de Pesquisa em Protocolos de  Redes de Computadores
> Membro do IEEE (ComSoc), do SBrT, do IECOM e da APEET
> 
> Universidade de Pernambuco/Escola Politécnica de Pernambuco
> Rua Benfica, 455 (Bl. 'C' 2. andar) - Bairro: Madalena
> CEP 50720-001 - Recife, Pernambuco - Brasil
> Fone: +55 81 3184-7542 - Fax: +55 81 3184-7581
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] jsonrpc

[Ben Pfaff]

On Mon, Nov 13, 2017 at 06:47:05PM -0300, Edison Albuquerque wrote:
> Sorry if this has been asked before.
> There's few examples on how to use jsonrpc to insert an interface, for
> example.
> For us, newbies, examples are extremely valuable, more than a thousand
> words.
> If some kind soul has an example on how to insert a new interface (s1-eth3)
> in a single switch (s1) with two interfaces (s1-eth2 and s1-eth3) please
> share with me.
> That would be a complete example, including Port and Bridge atualizations.

If you run something like this:
ovs-vsctl -vjsonrpc -- add-bond s1 s1-eth3 s1-eth2 s1-eth3
then you will see what ovs-vsctl does to insert such a bond, logged as
the jsonrpc module.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Regarding queue size for each queue configured on openvswitch by using SDN (RYU) controller

[Ben Pfaff]

OVS doesn't have queues of its own.  If you want to control queuing for
the Linux kernel datapath, and the existing Linux network queuing
disciplines don't do what you want, you should create a new Linux
network queuing discipline that does what you want.

On Mon, Nov 13, 2017 at 11:52:02AM -0800, ANKUR SHETH wrote:
> Hello Ben,
> 
> Thank you so much for your response. I appreciate your time and cooperation.
> 
> Now that I have figured out its not possible to manage the buffer size
> using linux tc, I would like to work on the buffer for the openvswitch.
> 
> Could you let me know if there is buffer in openvswitch where the packets
> are stored or if I need to create a buffer? I have found the functions
> related to the buffer size in the lib folder of openvswitch, but I am not
> able to understand where the function byteq_init(), etc. are called.
> 
> Could you point me to the correct documentation where I can find the
> details about how the packet id processed in the openvswitch so that I can
> create a buffer and then manage its size using the byteq_init() function
> which is defined in the lib folder of openvswitch.
> 
> Awaiting for your response.
> 
> Regards,
> Ankur
> 
> On Sat, Oct 21, 2017 at 2:25 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > On Fri, Oct 20, 2017 at 10:37:27PM -0700, ANKUR SHETH wrote:
> > > I am currently working on the queue control and bandwidth control for
> > > openvswitches using the SDN controller.
> > >
> > > I am able to configure the multiple queues with required max and min
> > > bandwidth rates) for the egress port , but I also want to limit the size
> > of
> > > the queue for the egress traffic for a particular port, which I am not
> > able
> > > to do.
> > >
> > > I actually intend to control the buffer size for the ingress as well as
> > > egress traffic via openvswitch.
> > >
> > > Could you please suggest on how I can achieve it or guide me to some
> > > documentation. Any help is appreciated.
> >
> > OVS doesn't have queues of its own, so this is a matter of configuring
> > Linux devices' traffic control, with "tc".  If you figure out
> > appropriate commands to do that, and you think that OVS should be able
> > to configure them for you, let us know and we can talk it over.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS queues and precedence

[Ben Pfaff]

On Mon, Nov 13, 2017 at 08:13:57PM +0100, Łukasz Rząsik wrote:
> 2017-10-25 0:05 GMT+02:00 Ben Pfaff <b...@ovn.org>:
> 
> > On Wed, Oct 18, 2017 at 09:17:53AM +0200, Jannis Ohms wrote:
> > > Hi
> > >
> > >
> > > I used the following command to create 4 queues
> > >
> > > ovs-vsctl -- set port s7-eth2 qos=@newqos -- --id=@newqos create qos
> > > type=linux-htb other-config:max-rate=1000 queues:1=@newQ
> > queues:2=@newQ2
> > > queues:3=@newQ3 -- --id=@newQ create queue other-config:min-rate=200
> > > other-config:max-rate=200,2=@newQ2 -- --id=@newQ2 create queue
> > > other-config:min-rate=200 other-config:max-rate=500,3=@newQ3 --
> > > --id=@newQ3 create queue other-config:min-rate=200
> > > other-config:max-rate=600
> > >
> > > Now I wanted to know which queues precede each other i.e. if every queue
> > has
> > > a token and a packet to send who comes first. I requier this knowledge to
> > > address the latency aspect of my QoS.
> > >
> > > I looked into Linux tc-htb manpage (https://linux.die.net/man/8/tc-htb)
> > >
> > > They define a prio property which seems to define  the precedence between
> > > the queues.
> > >
> > > Can I pass this as an aditional parameter via ovs-vsctl
> >
> > OVS doesn't currently support the prio (priority) setting, and currently
> > sets all priorities to 0.  If you want to submit a patch to add support
> > for this feature, I think it would be a reasonable addition.
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >
> 
> Hi Ben, Jannis,
> 
> I was about to implement prio (priority) setting for htb but I realized it
> is actually implemented.
> At least when I set other-config:priority for a given port then I can see
> it set correctly with tc class show.
> 
> Am I right or am I missing something? Maybe you meant something else?

Oh, that's funny.  You're right, and it's even documented.  I checked
the source before I replied, but I must have been looking at some other
QoS discipline.

Jannis, what's wrong with what's there?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Error communicating with sb database

[Ben Pfaff]

On Mon, Nov 13, 2017 at 12:38:27PM +0100, Sverker Abrahamsson wrote:
> Since an update of ovn/openvswitch the slave switches can't connect to the
> master database. In the ovsdb-server-sb.log I get messages like the below:
> 
> 2017-11-13T09:59:35.080Z|00210|stream_ssl|WARN|SSL_accept: error:140760FC:SSL 
> routines:SSL23_GET_CLIENT_HELLO:unknown protocol
> 2017-11-13T09:59:35.080Z|00211|stream_ssl|WARN|Dropped 2 log messages in last 
> 8 seconds (most recently, 2 seconds ago) due to excessive rate
> 2017-11-13T09:59:35.080Z|00212|stream_ssl|WARN|ssl:148.251.126.50:46994: 
> received JSON-RPC data on SSL channel
> 2017-11-13T09:59:35.080Z|00213|jsonrpc|WARN|Dropped 2 log messages in last 8 
> seconds (most recently, 2 seconds ago) due to excessive rate
> 2017-11-13T09:59:35.080Z|00214|jsonrpc|WARN|ssl:148.251.126.50:46994: receive 
> error: Protocol error
> 2017-11-13T09:59:35.080Z|00215|reconnect|WARN|ssl:148.251.126.50:46994: 
> connection dropped (Protocol error)
> 2017-11-13T09:59:40.974Z|00216|stream_ssl|WARN|SSL_accept: error:140760FC:SSL 
> routines:SSL23_GET_CLIENT_HELLO:unknown protocol
> 2017-11-13T09:59:40.974Z|00217|reconnect|WARN|ssl:144.76.84.73:45864: 
> connection dropped (Protocol error)
> 2017-11-13T09:59:43.088Z|00218|stream_ssl|WARN|SSL_accept: error:140760FC:SSL 
> routines:SSL23_GET_CLIENT_HELLO:unknown protocol
> 2017-11-13T09:59:43.106Z|00219|reconnect|WARN|ssl:148.251.126.50:47006: 
> connection dropped (Protocol error)
> 
> I do not have SSL enabled, did it become mandatory?

The message "ssl:148.251.126.50:46994: received JSON-RPC data on SSL
channel" indicates that ovsdb-server is listening for SSL connections on
the specified IP and port, but it's receiving plain old TCP connections.
SSL isn't mandatory but perhaps the defaults changed?  You should adjust
the ovsdb-server so it is listening for tcp connections.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-dpctl problem

[Ben Pfaff]

On Fri, Nov 10, 2017 at 07:44:23PM +0800, 焦利涛 wrote:
> Hi ：
>  I have a problem that when i use the ovs-dpctl to add a flow into 
> datapath, it occurs "ovs-dpctl: parsing flow key (Invalid argument)"
> 
> example:
> root@jlt:~# ovs-dpctl add-flow system@myDP 
> "in_port(1),eth_type(0x800),ipv4(src=172.31.110.4,dst=172.31.110.5)" 2
> ovs-dpctl: parsing flow key (Invalid argument)

The syntax understood by ovs-dpctl is very restrictive.  I suggest
looking at the output of "ovs-dpctl dump-flows", then imitating it
carefully.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] hardware offloading in ovs-2.8

[Ben Pfaff]

On Tue, Nov 07, 2017 at 03:49:06PM +0800, 王嵘 wrote:
> Hi,
> I'm using ovs-dpdk（ovs2.8/dpdk17.05.2), and I want to use the offload 
> feature. But I dont know how to enable it?
> As is represented in the release note 2.8:
> 
>- Addexperimental support for hardware offloading
>  * HW offloading is disabled by default.
> 
>  * HW offloading is done through the TC interface.

Do you have a supported NIC?  This feature is currently for a particular
model of Mellanox NICs.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] group entries are not deleted after del-controller command

[Ben Pfaff]

On Fri, Nov 03, 2017 at 02:37:02PM +, Periyasamy Palanisamy wrote:
> I have OVS 2.6.1 configured with bridge br-int in fail_mod set to 'secure'.
> 
> There are flows and groups configured by controller in the switch for a VM 
> attached to it.
> 
> 
> 
> After running 'ovs-vsctl del-controller br-int', only flow entries are wiped 
> out. Groups are not removed.

Deleting groups has just never been part of the way that OVS defines
this to happen.  Now that you point it out, I think that it should be.
I sent out a patch to implement that behavior:
https://patchwork.ozlabs.org/patch/835093/

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

Re: [ovs-discuss] nd_target is not working at IPv6

[Ben Pfaff]

On Fri, Nov 03, 2017 at 04:18:25PM +0200, Andrey Ziltsov wrote:
> Hallo!!!
> 
> We have a problem with flow field "nd_target" at IPv6.
> 
> For example.
> 
> We have two VM with virtual interfaces vnet0 and vnet1.
> 
> At the bridge set fail_mode to "secure":
> 
> *# ovs-vsctl list br public-switch | grep fail_mode*
> fail_mode   : secure
> 
> The interface bond0.6 is external interface.
> 
> We added only three flows for the test :
> 
> *# ovs-ofctl --no-stat dump-flows public-switch --sort=priority*
>  cookie=0x123575, table=2, priority=1,icmp6,icmp_type=135
> actions=output:vnet1
>  cookie=0x124994, table=2,
> priority=108,icmp6,icmp_type=135,nd_target=::2:2::a5
> actions=output:vnet0
>  cookie=0x10005, priority=10005,icmp6,in_port="bond0.6",icmp_type=135
> actions=resubmit(,2)
> 
> So, all ICMP6 traffic with type 135 going on bond0.6 resubmit to table 2
> and the if nd_target field equals to IPv6 address ::2:2::a5 the
> traffic send to vnet0 (VM1 have IPv6 ::2:2::a5). All other traffic
> should go to vnet1 (VM2).

Hmm, that does seem wrong.  Can you try out an example packet with
"ovs-appctl ofproto/trace" and paste the output?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] IPsec offloading

[Ben Pfaff]

On Thu, Nov 02, 2017 at 03:40:16PM +, Stokes, Ian wrote:
> > Does the OVS support HW IPsec offload ? can OVS configure the NIC/Network
> > adapter to ipsec a specific flow ?
> 
> Hi Avi, this feature isn't available in OVS currently from what I'm aware of.

Is there some reason that OVS would disable IPsec offload features
otherwise supported by Linux?  I guess that this question is not about
DPDK, since OVS doesn't support IPsec at all with DPDK (yet).
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] misc.packet_dump issue.

[Ben Pfaff]

I don't think this is an OVS problem.  You should probably ask about it
on a POX or mininet mailing list.

On Thu, Nov 02, 2017 at 01:28:28PM +, Lewis Koh via discuss wrote:
> Reference to Using POX components to create a software defined networking 
> application -> Start POX
> 
> | 
> | 
> | 
> |  |  |
> 
>  |
> 
>  |
> | 
> |  | 
> Using POX components to create a software defined networking application
> 
> When network engineers are learning the concepts of software defined 
> networking and SDN controllers, they may wa...
>  |
> 
>  |
> 
>  |
> 
> 
> 
> I'm running betta and I'm trying this command below
> $ sudo ~/pox/pox.py forwarding.l2_learning 
> openflow.spanning_tree --no-flood --hold-down 
> log.level --DEBUG samples.pretty_log 
> openflow.discovery host_tracker 
> info.packet_dump
> 
> I encounter the following message
> Module not found: info.packet_dump.
> I found that there is no "info" folder in POX folder but there is a 
> packet_dump.py in "misc" folder.  I changed the command to run 
> misc.packet.dump but my error message changed to this:
> mininet@mininet-vm:~/pox/pox$ sudo ~/pox/pox.py forwarding.l2_learning   
> openflow.spanning_tree --no-flood --hold-down   log.level --DEBUG 
> samples.pretty_log   openflow.discovery host_tracker   misc.packet_dump    
> POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et 
> al.[openflow.spanning_tree ] Spanning tree component ready[host_tracker       
>     ] host_tracker ready[misc.packet_dump       ] Packet dumper running[core  
>                  ] POX 0.1.0 (betta) going up...[core                   ] 
> Running on CPython (2.7.6/Oct 26 2016 20:30:19)[core                   ] 
> Platform is Linux-4.2.0-27-generic-x86_64-with-Ubuntu-14.04-trusty[core       
>             ] POX 0.1.0 (betta) is up.Task  caused 
> exception and was de-scheduledTraceback (most recent call last):  File 
> "/home/mininet/pox/pox/lib/recoco/recoco.py", line 276, in cycle    rv = 
> t.execute()  File "/home/mininet/pox/pox/lib/recoco/recoco.py", line 94, in 
> execute    return self.gen.send(v)  File 
> "/home/mininet/pox/pox/openflow/of_01.py", line 842, in run    
> listener.bind((self.address, self.port))  File 
> "/usr/lib/python2.7/socket.py", line 224, in meth    return 
> getattr(self._sock,name)(*args)error: [Errno 98] Address already in use
> How should I debug this??

> ___
> 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] Unable to run miniedit

[Ben Pfaff]

I don't think this is an OVS problem.  You should probably ask about it
on a mininet mailing list.

On Thu, Nov 02, 2017 at 12:57:20PM +, Lewis Koh via discuss wrote:
>  I tried to run a topology using miniedit and encountered the following 
> messages. I had tried sudo mn -c and also sudo killall controllers and sudo 
> killallovs-controllers but still get these msgs. Pls help.
> mininet@mininet-vm:~/mininet/examples$ sudo ./miniedit.pyMiniEdit running 
> against Mininet 2.2.2topo=noneBuild network based on our topology.Getting 
> Hosts and Switches. 'mininet.node.Host'> 'mininet.node.Host'>Getting controller 
> selection:refException in Tkinter callbackTraceback (most recent call last):  
> File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1489, in __call__    return 
> self.func(*args)  File "./miniedit.py", line 1379, in doRun    self.start()  
> File "./miniedit.py", line 3005, in start    self.net = self.build()  File 
> "./miniedit.py", line 2906, in build    self.buildNodes(net)  File 
> "./miniedit.py", line 2859, in buildNodes    port=controllerPort)  File 
> "build/bdist.linux-x86_64/egg/mininet/net.py", line 261, in addController    
> controller_new = controller( name, **params )  File 
> "build/bdist.linux-x86_64/egg/mininet/node.py", line 1367, in __init__    
> self.checkListening()  File "build/bdist.linux-x86_64/egg/mininet/node.py", 
> line 1385, in checkListening    '\n'.join( clist ) )Exception: Please shut 
> down the controller which is running on port 6633:Active Internet connections 
> (servers and established)tcp        0      0 0.0.0.0:6633            
> 0.0.0.0:*               LISTEN      6339/python2.7  tcp        0      0 
> 127.0.0.1:6633          127.0.0.1:44418         SYN_RECV    -               
> tcp        9      0 127.0.0.1:6633          127.0.0.1:44196         
> CLOSE_WAIT  -               tcp        9      0 127.0.0.1:6633          
> 127.0.0.1:44216         CLOSE_WAIT  -               tcp        9      0 
> 127.0.0.1:6633          127.0.0.1:44200         CLOSE_WAIT  -               
> tcp        1      0 127.0.0.1:6633          127.0.0.1:44194         
> CLOSE_WAIT  -               tcp        9      0 127.0.0.1:6633          
> 127.0.0.1:44226         CLOSE_WAIT  -               tcp        9      0 
> 127.0.0.1:6633          127.0.0.1:44210         CLOSE_WAIT  -               
> tcp        9      0 127.0.0.1:6633          127.0.0.1:44222         
> CLOSE_WAIT  -               tcp        9      0 127.0.0.1:6633          
> 127.0.0.1:44208         CLOSE_WAIT  -               tcp        0      1 
> 127.0.0.1:44418         127.0.0.1:6633          FIN_WAIT1   -               
> tcp        9      0 127.0.0.1:6633          127.0.0.1:44202         
> CLOSE_WAIT  -               tcp        9      0 127.0.0.1:6633          
> 127.0.0.1:44206         CLOSE_WAIT  -               tcp        9      0 
> 127.0.0.1:6633          127.0.0.1:44214         CLOSE_WAIT  -               
> tcp        9      0 127.0.0.1:6633          127.0.0.1:44198         
> CLOSE_WAIT  -               tcp        9      0 127.0.0.1:6633          
> 127.0.0.1:44212         CLOSE_WAIT  -               tcp        9      0 
> 127.0.0.1:6633          127.0.0.1:44204         CLOSE_WAIT  -               
> tcp        9      0 127.0.0.1:6633          127.0.0.1:44218         
> CLOSE_WAIT  -               tcp        9      0 127.0.0.1:6633          
> 127.0.0.1:44224         CLOSE_WAIT  -               tcp        9      0 
> 127.0.0.1:6633          127.0.0.1:44220         CLOSE_WAIT  -               
> 

> ___
> 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] OpenvSwitch Website

[Ben Pfaff]

On Wed, Nov 01, 2017 at 01:46:34PM +, Michael Williams wrote:
> Is there a problem with the http://openvswitch.org/ website? I noticed
> that it became unreachable last night and its still appears to be
> down.

I think its linode got shut down.  I don't know why.  Maybe it crashed.

You can use openvswitch.github.io for now.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Default Openflow Ports

[Ben Pfaff]

On Thu, Oct 26, 2017 at 12:08:48AM +, Tommy Romano wrote:
> We’re trying to manually set the openflow port numbers for our OVS
> bridge ports. What port numbers should we avoid setting? I thought it
> was 1-16k and 65534-65535 that are allocated by OVS, but wanted to
> confirm.

I don't really understand this question.  OpenFlow usually runs on port
6653, or sometimes on the legacy port number 6633.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] [OVN] OVN doesn't work using OVS 2.8.1 on Centos 7.3 using conntrack

[Ben Pfaff]

On Wed, Oct 25, 2017 at 06:50:29PM +0530, Numan Siddique wrote:
> On Wed, Oct 25, 2017 at 3:09 PM, Daniel Alvarez Sanchez <dalva...@redhat.com
> > wrote:
> 
> >
> >
> > On Tue, Oct 24, 2017 at 11:35 PM, Ben Pfaff <b...@ovn.org> wrote:
> >
> >> On Tue, Oct 24, 2017 at 02:27:59PM -0700, Ben Pfaff wrote:
> >> > On Tue, Oct 24, 2017 at 11:07:58PM +0200, Daniel Alvarez Sanchez wrote:
> >> > > Hi guys,
> >> > >
> >> > > Great job Numan!
> >> > > As we discussed over IRC, the patch below may make more sense.
> >> > > It essentially sets the dl_type so that when packet comes from the
> >> > > controller, it matches
> >> > > a valid type and OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4 is not added.
> >> > > Maybe what Numan proposed and this patch could be a good combination
> >> but I
> >> > > think
> >> > > that we definitely need to set the dl_type as it's later checked in
> >> > > pkt_metadata_from_flow()
> >> > > and it'll be zero there otherwise.
> >> > > What do you guys think? I have tried the patch below and the kernel
> >> error
> >> > > is not shown
> >> > > anymore when issuing DHCP requests.
> >> > >
> >> > >
> >> > > diff --git a/lib/flow.c b/lib/flow.c
> >> > > index b2b10aa..62b948f 100644
> >> > > --- a/lib/flow.c
> >> > > +++ b/lib/flow.c
> >> > > @@ -1073,6 +1073,7 @@ flow_get_metadata(const struct flow *flow,
> >> struct
> >> > > match *flow_metadata)
> >> > >
> >> > >  if (flow->ct_state != 0) {
> >> > >  match_set_ct_state(flow_metadata, flow->ct_state);
> >> > > +match_set_dl_type(flow_metadata, flow->dl_type);
> >> > >  if (is_ct_valid(flow, NULL, NULL) && flow->ct_nw_proto != 0)
> >> {
> >> > >  if (flow->dl_type == htons(ETH_TYPE_IP)) {
> >> > >  match_set_ct_nw_src(flow_metadata, flow->ct_nw_src);
> >> >
> >> > This patch seems reasonable too.
> >> >
> >> > I recommend adding a comment above it to explain what's going on,
> >> > because dl_type is not a metadata field and it's confusing to deal with
> >> > it in a context that's supposed to be all about metadata.  I guess the
> >> > comment would essentially say that dl_type is essential to the
> >> > interpretation of the conntrack metadata.
> >>
> >> Oh, and for this patch too I'd welcome a formal patch proposal.
> >>
> >
> > Done. Thanks a lot Ben.
> > If this get merged, it would be great if we can get it into 2.8 branch and
> > add a new tag (2.8.2).
> >
> > Thanks!!
> >
> 
> Ben, we have submitted both the patches. The patch from Daniel - (
> https://patchwork.ozlabs.org/patch/830160/)  will fix the issue.
> Not sure if this patch  https://patchwork.ozlabs.org/patch/830132/ is
> needed any more.
> 
> Request to review these patches if possible as RDO is blocked on these
> patches before we can  update from OVS 2.7.2 to OVS 2.8(.2)

I've reviewed both.  I wasn't able to immediately apply either one, but
they're obviously moving in the right direction, so I'd appreciate
follow-up from both of you so that we can get them in.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] About the 'clone' action

[Ben Pfaff]

On Wed, Oct 25, 2017 at 06:07:41PM +0800, Hui Xiang wrote:
> I think I am finally catching a bit with the concept of 'clone' action
> after reviewing below patches in order, so the for OVN case, the new
> 'clone' action aims to drop most of the OVS patch port, and after add new
> ct_clear action, some fixes, I assume it works with NAT, and I am using
> 2.8.1 for testing, please point out the patches if I am missing any. 

I think that should work fine.  There are a few bug fixes on branch-2.8
that are not in any v2.8.x release, but I don't think that they will
affect OVN.

> One other question is Can I set bridge-mapping:physnet1:br-int? In
> other words, the br-int has vm vif, has tunnel ports(the tunnel ports
> would point to another nic), and has the external nic as local gateway
> router port, is it feasible without configuring more extra flows.

I don't think OVN contemplates br-int being using as a bridge mapping.
My guess is that that would fail.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS Flow insert

[Ben Pfaff]

On Wed, Oct 25, 2017 at 05:13:03PM +0300, Sara Gittlin wrote:
> Can someone refer to the code where a  new flow is inserted to
> openflow tables in the OVS, as a consequence action of a received
> message from a controller?

handle_flow_mod() in ofproto.c
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS queues and precedence

[Ben Pfaff]

On Wed, Oct 18, 2017 at 09:17:53AM +0200, Jannis Ohms wrote:
> Hi
> 
> 
> I used the following command to create 4 queues
> 
> ovs-vsctl -- set port s7-eth2 qos=@newqos -- --id=@newqos create qos
> type=linux-htb other-config:max-rate=1000 queues:1=@newQ queues:2=@newQ2
> queues:3=@newQ3 -- --id=@newQ create queue other-config:min-rate=200
> other-config:max-rate=200,2=@newQ2 -- --id=@newQ2 create queue
> other-config:min-rate=200 other-config:max-rate=500,3=@newQ3 --
> --id=@newQ3 create queue other-config:min-rate=200
> other-config:max-rate=600
> 
> Now I wanted to know which queues precede each other i.e. if every queue has
> a token and a packet to send who comes first. I requier this knowledge to
> address the latency aspect of my QoS.
> 
> I looked into Linux tc-htb manpage (https://linux.die.net/man/8/tc-htb)
> 
> They define a prio property which seems to define  the precedence between
> the queues.
> 
> Can I pass this as an aditional parameter via ovs-vsctl

OVS doesn't currently support the prio (priority) setting, and currently
sets all priorities to 0.  If you want to submit a patch to add support
for this feature, I think it would be a reasonable addition.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] [OVN] OVN doesn't work using OVS 2.8.1 on Centos 7.3 using conntrack

[Ben Pfaff]

On Tue, Oct 24, 2017 at 02:27:59PM -0700, Ben Pfaff wrote:
> On Tue, Oct 24, 2017 at 11:07:58PM +0200, Daniel Alvarez Sanchez wrote:
> > Hi guys,
> > 
> > Great job Numan!
> > As we discussed over IRC, the patch below may make more sense.
> > It essentially sets the dl_type so that when packet comes from the
> > controller, it matches
> > a valid type and OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4 is not added.
> > Maybe what Numan proposed and this patch could be a good combination but I
> > think
> > that we definitely need to set the dl_type as it's later checked in
> > pkt_metadata_from_flow()
> > and it'll be zero there otherwise.
> > What do you guys think? I have tried the patch below and the kernel error
> > is not shown
> > anymore when issuing DHCP requests.
> > 
> > 
> > diff --git a/lib/flow.c b/lib/flow.c
> > index b2b10aa..62b948f 100644
> > --- a/lib/flow.c
> > +++ b/lib/flow.c
> > @@ -1073,6 +1073,7 @@ flow_get_metadata(const struct flow *flow, struct
> > match *flow_metadata)
> > 
> >  if (flow->ct_state != 0) {
> >  match_set_ct_state(flow_metadata, flow->ct_state);
> > +match_set_dl_type(flow_metadata, flow->dl_type);
> >  if (is_ct_valid(flow, NULL, NULL) && flow->ct_nw_proto != 0) {
> >  if (flow->dl_type == htons(ETH_TYPE_IP)) {
> >  match_set_ct_nw_src(flow_metadata, flow->ct_nw_src);
> 
> This patch seems reasonable too.
> 
> I recommend adding a comment above it to explain what's going on,
> because dl_type is not a metadata field and it's confusing to deal with
> it in a context that's supposed to be all about metadata.  I guess the
> comment would essentially say that dl_type is essential to the
> interpretation of the conntrack metadata.

Oh, and for this patch too I'd welcome a formal patch proposal.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] [OVN] OVN doesn't work using OVS 2.8.1 on Centos 7.3 using conntrack

[Ben Pfaff]

On Tue, Oct 24, 2017 at 11:07:58PM +0200, Daniel Alvarez Sanchez wrote:
> Hi guys,
> 
> Great job Numan!
> As we discussed over IRC, the patch below may make more sense.
> It essentially sets the dl_type so that when packet comes from the
> controller, it matches
> a valid type and OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4 is not added.
> Maybe what Numan proposed and this patch could be a good combination but I
> think
> that we definitely need to set the dl_type as it's later checked in
> pkt_metadata_from_flow()
> and it'll be zero there otherwise.
> What do you guys think? I have tried the patch below and the kernel error
> is not shown
> anymore when issuing DHCP requests.
> 
> 
> diff --git a/lib/flow.c b/lib/flow.c
> index b2b10aa..62b948f 100644
> --- a/lib/flow.c
> +++ b/lib/flow.c
> @@ -1073,6 +1073,7 @@ flow_get_metadata(const struct flow *flow, struct
> match *flow_metadata)
> 
>  if (flow->ct_state != 0) {
>  match_set_ct_state(flow_metadata, flow->ct_state);
> +match_set_dl_type(flow_metadata, flow->dl_type);
>  if (is_ct_valid(flow, NULL, NULL) && flow->ct_nw_proto != 0) {
>  if (flow->dl_type == htons(ETH_TYPE_IP)) {
>  match_set_ct_nw_src(flow_metadata, flow->ct_nw_src);

This patch seems reasonable too.

I recommend adding a comment above it to explain what's going on,
because dl_type is not a metadata field and it's confusing to deal with
it in a context that's supposed to be all about metadata.  I guess the
comment would essentially say that dl_type is essential to the
interpretation of the conntrack metadata.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] [OVN] OVN doesn't work using OVS 2.8.1 on Centos 7.3 using conntrack

[Ben Pfaff]

On Tue, Oct 24, 2017 at 09:04:22PM +0530, Numan Siddique wrote:
> We did some more investigation. This issue is seen only when OVN  native
> dhcp is used and with kernel datapath which doesn't support
> OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4.  The reason for this failure is because
> ovs-vswitchd includes the attribute OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4 when it
> sends the packet back to the datapath after the dhcp reply packet is
> resumed.
> 
> When the dhcp packet is sent to ovn-controller, the ct_state value is set
> to 0x21 and dl_type is set to 0 in the flow metadata. When the packet is
> resumed, the function nxt_resume() calls 'pkt_metadata_from_flow()' which
> neither sets 'md->ct_orig_tuple' or memsets it [1] because is_ct_valid()
> returns true and dl_type is 0. And the function odp_key_from_dp_packet()
> adds OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4 [2]
> 
> This issue is not seen in master because of this commit - "f6fabcc624
> ofproto-dpif: Mark packets as "untracked" after call to ct()" [3]
> 
> This patch clears the conn track variables after the ct() action.
> 
> I suppose we cannot apply this patch to OVS 2.8 branch because it was
> reverted [4] due to some issues.
> 
> I think we can solve this problem either with the below fixe or by setting
> dl_type to proper value when the packet is sent to controller.
> 
> ***
> diff --git a/lib/flow.h b/lib/flow.h
> index 6ae5a674d..076ce36f1 100644
> --- a/lib/flow.h
> +++ b/lib/flow.h
> @@ -947,6 +947,8 @@ pkt_metadata_from_flow(struct pkt_metadata *md, const
> struct flow *flow)
>  flow->ct_tp_dst,
>  flow->ct_nw_proto,
>  };
> +} else {
> +memset(>ct_orig_tuple, 0, sizeof md->ct_orig_tuple);
>  }
>  } else {
>  memset(>ct_orig_tuple, 0, sizeof md->ct_orig_tuple);
> **
> 
> Please let me know if this fix makes sense ? Or if there is a better way to
> solve it ?

I think that is a reasonable patch.  Will you please propose it as a
formal patch?  Please include a thorough commit message.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-vswitch Huge number of netlink file descriptors open

[Ben Pfaff]

Can you provide your configuration database, that is,
ovs-vswitchd.conf.db?

On Sat, Oct 21, 2017 at 01:44:42PM +0800, quan_hp...@heetian.com wrote:
> Hi,All,
> The  file descriptors are "netlink".
>  $sudo lsof -p $(pidof ovs-vswitchd)
> ovs-vswit 2197 root *297u  netlink 0t0   42309398 
> GENERIC
> ovs-vswit 2197 root *298u  netlink 0t0   42309399 
> GENERIC
> ovs-vswit 2197 root *299u sock0,7  0t0   42309400 
> protocol: NETLINK
> ovs-vswit 2197 root *300u  netlink 0t0   42309401 
> GENERIC
> ovs-vswit 2197 root *301u  netlink 0t0   42309402 
> GENERIC
> ...More...
> ovs-vswit 2197 root *351u  netlink 0t0   39326247 
> GENERIC
> ovs-vswit 2197 root *352u  netlink 0t0   39121841 
> GENERIC
> ovs-vswit 2197 root *354w  REG  253,0 10086253 1342248977 
> /var/log/openvswitch/ovs-vswitchd.log
> $sudo reboot
> When I restart the machine ,the file descriptor will increasing.Some time 
> more then 12K record.
> 
> Recenty log about openvswitch.
> ovsdb-server.log
> 2017-10-21T04:01:02.559Z|01308|jsonrpc|WARN|Dropped 7 log messages in last 17 
> seconds (most recently, 10 seconds ago) due to excessive rate
> 2017-10-21T04:01:02.559Z|01309|jsonrpc|WARN|unix: receive error: Connection 
> reset by peer
> 2017-10-21T04:01:02.560Z|01310|reconnect|WARN|unix: connection dropped 
> (Connection reset by peer)
> 2017-10-21T04:01:03.282Z|01311|reconnect|WARN|unix: connection dropped 
> (Connection reset by peer)
> 2017-10-21T04:01:10.075Z|01312|jsonrpc|WARN|Dropped 1 log messages in last 7 
> seconds (most recently, 7 seconds ago) due to excessive rate
> 2017-10-21T04:01:10.075Z|01313|jsonrpc|WARN|unix: send error: Broken pipe
> 2017-10-21T04:01:10.076Z|01314|reconnect|WARN|unix: connection dropped 
> (Broken pipe)
> 2017-10-21T04:01:14.907Z|01315|reconnect|WARN|unix: connection dropped 
> (Connection reset by peer)
> 2017-10-21T04:01:20.134Z|01316|reconnect|WARN|unix: connection dropped 
> (Broken pipe)
> 2017-10-21T04:01:27.499Z|01317|jsonrpc|WARN|Dropped 2 log messages in last 13 
> seconds (most recently, 8 seconds ago) due to excessive rate
> 2017-10-21T04:01:27.499Z|01318|jsonrpc|WARN|unix: receive error: Connection 
> reset by peer
> 2017-10-21T04:01:27.499Z|01319|reconnect|WARN|unix: connection dropped 
> (Connection reset by peer)
> 2017-10-21T04:01:33.758Z|01320|jsonrpc|WARN|unix: receive error: Connection 
> reset by peer
> 2017-10-21T04:01:33.758Z|01321|reconnect|WARN|unix: connection dropped 
> (Connection reset by peer)
> 2017-10-21T04:01:34.489Z|01322|reconnect|WARN|unix: connection dropped 
> (Connection reset by peer)
> 2017-10-21T04:01:39.198Z|01323|reconnect|WARN|unix: connection dropped 
> (Connection reset by peer)
> 2017-10-21T04:01:41.569Z|01324|reconnect|WARN|unix: connection dropped 
> (Broken pipe)
> 2017-10-21T04:01:41.913Z|01325|reconnect|WARN|unix: connection dropped 
> (Broken pipe)
> 2017-10-21T04:01:42.365Z|01326|reconnect|WARN|unix: connection dropped 
> (Connection reset by peer)
> 
> ovs-vswitchd.log
> 2017-10-21T03:56:10.511Z|422666|netlink_socket|ERR|connect(0): Argument list 
> too long
> 2017-10-21T03:56:10.513Z|422667|netlink_socket|ERR|connect(0): Argument list 
> too long
> 2017-10-21T03:56:10.516Z|422668|netlink_socket|ERR|connect(0): Argument list 
> too long
> 2017-10-21T03:56:10.518Z|422669|netlink_socket|ERR|connect(0): Argument list 
> too long
> 2017-10-21T03:56:10.520Z|422670|netlink_socket|ERR|connect(0): Argument list 
> too long
> 2017-10-21T03:56:10.523Z|422671|netlink_socket|ERR|connect(0): Argument list 
> too long
> 2017-10-21T03:56:10.525Z|422672|netlink_socket|ERR|connect(0): Argument list 
> too long
> 
> 
> 
> 合天网安实验室-您身边的信息安全实验室 | quan_hp...@heetian.com
>  
> From: Ben Pfaff
> Date: 2017-10-21 01:41
> To: quan_hp...@heetian.com
> CC: ovs-discuss
> Subject: Re: [ovs-discuss] ovs-vswitch Huge number of netlink file 
> descriptors open
> On Fri, Oct 20, 2017 at 06:56:26PM +0800, quan_hp...@heetian.com wrote:
> > Hi All,
> > I searched a mail list like my problem.
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2017-March/043817.html 
> > 
> > $sudo lsof -p $(pidof ovs-vswitchd) | wc -l
> > 115536
> > $cat /proc/$(cat /var/run/openvswitch/ovs-vswitchd.pid)/limits | grep open
> > Max open files9999files
> > $ovs-vsctl show | grep -c Port
> > 905
> > If anyone has any suggestions for how to solve it?Thanks.
>  
> Can you find out what k

Re: [ovs-discuss] About the 'clone' action

[Ben Pfaff]

On Mon, Oct 23, 2017 at 04:28:53PM +0800, Hui Xiang wrote:
> I am trying to understand clone action deeply and checking the patch
> related with 'clone'[1], where said "The clone action provides an action
> envelope to enclose an action list." and "The clone action is very similar
> with the OpenFlow clone action recently added", but sorry I am not able to
> find any "clone" action definition in the OpenFlow spec[2], or any envelope
> 's kind of phrases, it just referred some clone(copy) of piple, am I
> looking in a wrong place?

Open vSwitch has two kinds of actions.  First, there are OpenFlow
actions, which include both standard actions and extension actions.
"clone" is an OpenFlow extension action implemented by Open vSwitch.
Second, there are datapath actions, which are an implementation detail
of Open vSwitch.  Open vSwitch has a datapath action also called
"clone", which does something similar to the OpenFlow extension "clone"
action but at the datapath level.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Regarding queue size for each queue configured on openvswitch by using SDN (RYU) controller

[Ben Pfaff]

On Fri, Oct 20, 2017 at 10:37:27PM -0700, ANKUR SHETH wrote:
> I am currently working on the queue control and bandwidth control for
> openvswitches using the SDN controller.
> 
> I am able to configure the multiple queues with required max and min
> bandwidth rates) for the egress port , but I also want to limit the size of
> the queue for the egress traffic for a particular port, which I am not able
> to do.
> 
> I actually intend to control the buffer size for the ingress as well as
> egress traffic via openvswitch.
> 
> Could you please suggest on how I can achieve it or guide me to some
> documentation. Any help is appreciated.

OVS doesn't have queues of its own, so this is a matter of configuring
Linux devices' traffic control, with "tc".  If you figure out
appropriate commands to do that, and you think that OVS should be able
to configure them for you, let us know and we can talk it over.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Rate limit based on IP

[Ben Pfaff]

On Fri, Oct 20, 2017 at 04:58:06PM +0800, BALL SUN wrote:
> I understood that OVS has rate shaping based on port, is there any way
> to perform rate shaping on IP level?

You can use the flow table to assign packets to queues based on
destination IP, then assign different queues different rates with QoS
configuration.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-vswitch Huge number of netlink file descriptors open

[Ben Pfaff]

On Fri, Oct 20, 2017 at 06:56:26PM +0800, quan_hp...@heetian.com wrote:
> Hi All,
> I searched a mail list like my problem.
> https://mail.openvswitch.org/pipermail/ovs-discuss/2017-March/043817.html 
> 
> $sudo lsof -p $(pidof ovs-vswitchd) | wc -l
> 115536
> $cat /proc/$(cat /var/run/openvswitch/ovs-vswitchd.pid)/limits | grep open
> Max open files9999files
> $ovs-vsctl show | grep -c Port
> 905
> If anyone has any suggestions for how to solve it?Thanks.

Can you find out what kinds of file descriptors are open?  Are they
sockets (and what kind), etc.?

This could be a file descriptor leak of some kind.  If it is, then
restarting OVS would fix it; if it is not, then restarting OVS will not
help, or at least not for long.  Can you figure out whether restarting
reduces the number of file descriptors, and by how much?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Cannot install meter

[Ben Pfaff]

On Mon, Oct 16, 2017 at 12:17:30PM +0200, Cédric MORIN wrote:
> I have a question regarding meters in OVS, I hope this is the correct mailing 
> list to ask it.
> 
> According to the FAQ "Since version 2.0, Open vSwitch has OpenFlow protocol 
> support for OpenFlow meters. Currently, only the userspace datapath 
> implements meters" (http://docs.openvswitch.org/en/latest/faq/qos/),
> and according to the release notes of v.2.8.0 : "The "meter" action is now 
> supported in the userspace datapath" 
> (http://openvswitch.org/releases/NEWS-2.8.0).
> So I suppose it is now possible to create meters in OVS 2.8.0.

Are you using the userspace datapath?  It is not the default, so you
need to configure it on your bridge.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Fwd: Send some information from openvswitch to floodlight controller

[Ben Pfaff]

On Fri, Oct 13, 2017 at 11:17:28AM +0530, Tanmay Jain wrote:
> Is there any way to generate a packet and add some information to it by
> writing a script at openvswitch and send it to floodlight controller. And
> after receiving that packet at controller how to use that information.

You can set metadata fields and then send the packet to the controller,
which can then read the metadata.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS bridge on boot in Debian

[Ben Pfaff]

A lot of this comes down to how OVS is an infrastructure layer.  Like
GCC or another compiler, it generally has to have a program to run
before it is very useful.  The documentation for using it in particular
scenarios generally belongs in the systems (controllers, etc.) that
layer on top of it to accomplish specific tasks.

On Fri, Oct 13, 2017 at 01:31:40PM +, Bruce Hartpence wrote:
> I have similar questions - it seems as though there is information everywhere 
> but sometimes you have to dig it out. Does anyone know about a repo that has 
> a collection of "standard" configs? One example I could use might be when 
> deploying NFV OVS instances among different hypervisor chassis.
> 
> Bruce Hartpence
> Professor, IST Dept., RIT
> 585-475-7938
> bhh...@rit.edu
> 
> CONFIDENTIALITY NOTE: The information transmitted, including attachments, is 
> intended only for the person(s) or entity to which it is addressed and may 
> contain confidential and/or privileged material. Any review, retransmission, 
> dissemination or other use of, or taking of any action in reliance upon this 
> information by persons or entities other than the intended recipient is 
> prohibited. If you received this in error, please contact the sender and 
> destroy any copies of this information.
> 
> From: ovs-discuss-boun...@openvswitch.org 
> [mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Omar Ramadan
> Sent: Thursday, October 12, 2017 7:55 PM
> To: Guru Shetty 
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] OVS bridge on boot in Debian
> 
> 
> A related question: What is the best way to configure a set of controllers? 
> Can I specify a set of controllers for my bridge to use in a similar fashion 
> in networking?
> 
> 
> From: 
> ovs-discuss-boun...@openvswitch.org
>  
> >
>  on behalf of Omar Ramadan >
> Sent: Thursday, October 12, 2017 4:47:10 PM
> To: Guru Shetty
> Cc: ovs-discuss@openvswitch.org
> Subject: [Potential Spoof] Re: [ovs-discuss] OVS bridge on boot in Debian
> 
> 
> Looks like I was missing the kernel module. Added "openvswitch-datapath-dkms" 
> and it works now.
> 
> 
> 
> Thanks!
> 
> 
> From: 
> ovs-discuss-boun...@openvswitch.org
>  
> >
>  on behalf of Omar Ramadan >
> Sent: Thursday, October 12, 2017 4:31:24 PM
> To: Guru Shetty
> Cc: ovs-discuss@openvswitch.org
> Subject: [Potential Spoof] Re: [ovs-discuss] OVS bridge on boot in Debian
> 
> 
> Hi Guru, Ben,
> 
> 
> 
> Thanks for the responses. I originally did a "make install" though I realized 
> there may be some packaging postinst scripts that may need to be run for it 
> to work. I built and installed openvswitch-common and openvswitch-switch.
> 
> 
> "ifup --allow=ovs br0" still fails to find br0 but I've made progress 
> nonetheless in the networking journal
> 
> vagrant@magma-dev:/etc/network$ sudo journalctl -u networking
> Oct 12 23:27:29 magma-dev ovs-vsctl[2127]: ovs|1|vsctl|INFO|Called as 
> ovs-vsctl --timeout=5 -- --may-exist add-port br0 eth0 --
> Oct 12 23:27:29 magma-dev networking[1875]: ovs-vsctl: Error detected while 
> setting up 'eth0'.  See ovs-vswitchd log for details.
> Oct 12 23:27:29 magma-dev networking[1875]: ovs-vsctl: The default log 
> directory is "/var/log/openvswitch".
> Oct 12 23:27:29 magma-dev ovs-vsctl[2202]: ovs|1|vsctl|INFO|Called as 
> ovs-vsctl --timeout=5 -- --may-exist add-port br0 eth0 --
> 
> vagrant@magma-dev:/var/log/openvswitch$ sudo less ovs-vswitchd.log
> 2017-10-12T23:27:31.123Z|00112|ofproto|ERR|failed to open datapath br0: No 
> such file or directory
> 2017-10-12T23:27:31.123Z|00113|bridge|ERR|failed to create bridge br0: No 
> such file or directory
> 
> What could be missing?
> 
> Best,
> Omar
> 
> 
> From: Guru Shetty >
> Sent: Thursday, October 12, 2017 10:50:38 AM
> To: Omar Ramadan
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] OVS bridge on boot in Debian
> 
> 
> 
> On 12 October 2017 at 10:29, Omar Ramadan 
> > wrote:
> 
> Hi list,
> 
> 
> 
> I am using OVS 2.7.90 with Debian 8.7 and want to configure the switch to be 
> loaded on system initialization. I have installed the service 
> "openvswitch-switch" and added the following in /etc/network/interfaces
> 
> How did you install OVS 2.7.90? By 'make install' or via debian packages?
> 
> 
> 
> allow-ovs br0
> iface br0 inet dhcp
> ovs_type OVSBridge
> ovs_ports eth0
> 
> 

Re: [ovs-discuss] OVS bridge on boot in Debian

[Ben Pfaff]

Usually "ovs-vsctl set-controller" is the best way to configure a set of
controllers.

But maybe you are asking about how to configure a set of controllers
from /etc/network/interfaces.  If so, Guru may have advice (and maybe we
should document it).

On Thu, Oct 12, 2017 at 11:54:54PM +, Omar Ramadan wrote:
> A related question: What is the best way to configure a set of controllers? 
> Can I specify a set of controllers for my bridge to use in a similar fashion 
> in networking?
> 
> 
> From: ovs-discuss-boun...@openvswitch.org 
>  on behalf of Omar Ramadan 
> 
> Sent: Thursday, October 12, 2017 4:47:10 PM
> To: Guru Shetty
> Cc: ovs-discuss@openvswitch.org
> Subject: [Potential Spoof] Re: [ovs-discuss] OVS bridge on boot in Debian
> 
> 
> Looks like I was missing the kernel module. Added "openvswitch-datapath-dkms" 
> and it works now.
> 
> 
> Thanks!
> 
> 
> From: ovs-discuss-boun...@openvswitch.org 
>  on behalf of Omar Ramadan 
> 
> Sent: Thursday, October 12, 2017 4:31:24 PM
> To: Guru Shetty
> Cc: ovs-discuss@openvswitch.org
> Subject: [Potential Spoof] Re: [ovs-discuss] OVS bridge on boot in Debian
> 
> 
> Hi Guru, Ben,
> 
> 
> Thanks for the responses. I originally did a "make install" though I realized 
> there may be some packaging postinst scripts that may need to be run for it 
> to work. I built and installed openvswitch-common and openvswitch-switch.
> 
> 
> "ifup --allow=ovs br0" still fails to find br0 but I've made progress 
> nonetheless in the networking journal
> 
> vagrant@magma-dev:/etc/network$ sudo journalctl -u networking
> Oct 12 23:27:29 magma-dev ovs-vsctl[2127]: ovs|1|vsctl|INFO|Called as 
> ovs-vsctl --timeout=5 -- --may-exist add-port br0 eth0 --
> Oct 12 23:27:29 magma-dev networking[1875]: ovs-vsctl: Error detected while 
> setting up 'eth0'.  See ovs-vswitchd log for details.
> Oct 12 23:27:29 magma-dev networking[1875]: ovs-vsctl: The default log 
> directory is "/var/log/openvswitch".
> Oct 12 23:27:29 magma-dev ovs-vsctl[2202]: ovs|1|vsctl|INFO|Called as 
> ovs-vsctl --timeout=5 -- --may-exist add-port br0 eth0 --
> 
> vagrant@magma-dev:/var/log/openvswitch$ sudo less ovs-vswitchd.log
> 2017-10-12T23:27:31.123Z|00112|ofproto|ERR|failed to open datapath br0: No 
> such file or directory
> 2017-10-12T23:27:31.123Z|00113|bridge|ERR|failed to create bridge br0: No 
> such file or directory
> 
> What could be missing?
> 
> Best,
> Omar
> 
> 
> 
> From: Guru Shetty 
> Sent: Thursday, October 12, 2017 10:50:38 AM
> To: Omar Ramadan
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] OVS bridge on boot in Debian
> 
> 
> 
> On 12 October 2017 at 10:29, Omar Ramadan 
> > wrote:
> 
> Hi list,
> 
> 
> I am using OVS 2.7.90 with Debian 8.7 and want to configure the switch to be 
> loaded on system initialization. I have installed the service 
> "openvswitch-switch" and added the following in /etc/network/interfaces
> 
> How did you install OVS 2.7.90? By 'make install' or via debian packages?
> 
> 
> 
> allow-ovs br0
> 
> iface br0 inet dhcp
> 
> ovs_type OVSBridge
> 
> ovs_ports eth0
> 
> 
> allow-br0 eth0
> 
> iface eth0 inet manual
> 
> ovs_bridge br0
> 
> ovs_type OVSPort
> 
> I am still unable to load br0 with ifup.
> 
> 
> vagrant@magma-dev:/etc/network/interfaces.d$ sudo ifup br0
> Lets try with:
> ifup --allow=ovs br0
> 
> 
> 
> Cannot find device "br0"
> 
> Bind socket to interface: No such device
> 
> 
> exiting.
> 
> Failed to bring up br0.
> 
> How do these interfaces get set up? Is there anyway to debug this? I've built 
> this package from source, so I want to make sure I am not missing 
> dependencies. Also should I be adding any additional systemctl units or 
> should adding "openvswitch-switch" be enough?
> 
> Best,
> Omar
> 
> ___
> 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] Does it work if netdev datapath connect system datapath through patch ports

[Ben Pfaff]

On Fri, Oct 13, 2017 at 06:04:16PM +0800, Hui Xiang wrote:
> Is the patch port output logistic within function apply_nested_clone_actions
> ? Sorry, I have not totally understood the whole picture on how a packet
> through
> the datapath flow on the case that goes from netdev datapath patch port_B
> to system datapath port_C. Is it such a procedure:
> When a packet arrives at patch port_B of netdev datapath br1, the xlate ctx
> switch to system datapath br2, and try to find a
> rule, the rule probably missed, but I didn't find where this rule should be
> preloaded, and why does it not work in this case.
> 
> Coud you help to guide?

Patch port output happens in patch_port_output() in ofproto-dpif-xlate.c.

Patch ports are implemented entirely within a datapath.  Output to one
happens by simply doing a nested translation of the actions that would
happen at the other end of the patch port.  This can't really happen if
the packet would pass to another datapath entirely.  One could implement
some feature for hopping from one datapath to another.  We have not done
this because the value of the feature seems limited; most installations
of OVS use only a single datapath.

> In additions, does it work with veth connected netdev datapath with system
> datapath? It seems OVN will bridge the br-int with
> the external network having another bridge with patch port, in this case,
> if br-int is netdev, but external bridge is system,
> then it doesn't work as what I understand so far.

veths should be able to hop from one datapath to another, at least for
datapaths that support veths.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Does it work if netdev datapath connect system datapath through patch ports

[Ben Pfaff]

On Thu, Oct 12, 2017 at 05:22:14PM +0800, Hui Xiang wrote:
>Seems it works with the same datapath type during the discussion in [1]
> by finally done a flow of leaving two kernel netdev port communicate
> together.
> 
>But in my case I have a setup with two bridges has different datapath
> type, netdev and system, need to be connected, port_A(in netdev datapath)
> is in running in the userspace, port_D(in system datapath), will the flow
> be port_A  port_D directly and packets go through userspace to
> kernelspace and so on in the reverse direction,
>  does patch port can make it work?

No, that doesn't work.  (I should document that.)
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] IGMP Snooping on OVS 2.7.0

[Ben Pfaff]

On Mon, Oct 09, 2017 at 04:08:24PM -0600, Sterdnot Shaken wrote:
> Just curious why, with igmp snooping enabled on the OVS bridge, I am still
> getting multicast traffic on other VM's (that shouldn't be getting it) on
> the same vlan?
> 
> Here's how I'm enabling IGMP Snooping:
> 
> 
> *ovs-vsctl set Bridge ovs-br mcast_snooping_enable=trueovs-vsctl set Bridge
> ovs-br other_config:mcast-snooping-disable-flood-unregistered=true*
> 
> Then, I run iperf between two nodes like this to simulate mcast traffic:
> 
> 
> *iperf -s -u -B 239.1.1.1 -i 1iperf -c 239.1.1.1 -u -T 32 -t 3 -i 1*
> 
> While this test is active, I see all this traffic on those other nodes in
> that same vlan...
> 
> Anyone have any ideas? Are their OVS commands that allow me to see more
> details regarding IGMP Snooping besides it being enabled/disabled?

Thank you for the report.

There is one IGMP related bug fix patch that got into 2.8 but didn't get
backported to previous versions.  I've now applied this to branch-2.7.
It would be a good idea to try it to see if it fixes the problem.

You should be able to find out more about multicast snooping activity by
turning up the log level for the ofproto-dpif-xlate module, e.g. with
"ovs-appctl vlog/set ofproto-dpif-xlate".
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

[Ben Pfaff]

OVS doesn't handle this case well.  I don't think it will do what you
want.

On Mon, Oct 09, 2017 at 11:59:13PM +0200, Juraj Markotic wrote:
> yes, we are already using that one to send packet across 2 OVS connected
> via GRE tunnels and when switched out, will remove GRE header.
> Imagine situation where SPAN traffic from some other switch is being sent
> as replica traffic to OVS inport (one can be configured as GRE port for
> that matter). Packets coming to OVs inport are mostly GRE traffic with
> varying src/dst ip in GRE haders  since this is replica traffic from
> network. This is not  traffic directed to ip configured on that exact OVS
> (which is receiving it).
> Would OVS just drop this receiving traffic or will remove header without
> checking and be switch it as configured (i.e. via openflow rule) ?
> I guess we'd need to check.
> 
> jm
> 
> 
> On Mon, Oct 9, 2017 at 11:14 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > GRE and tunnels are implemented in terms of ports, so if you send a
> > packet received on a GRE port to a non-tunnel port, it strips the
> > header.
> >
> > On Mon, Oct 09, 2017 at 10:45:10PM +0200, Juraj Markotic wrote:
> > > I will check on about GTP ongoing activities (I saw some actitvities on
> > > providing capabilities to match on GTP-C/GTP-U packets).
> > > maybe dumb question, but any pointer on how to remove GRE header (or
> > VXLAN
> > > for that matter) when switching packet from IN port to OUT port and
> > switch
> > > out only internal packet/payload ?
> > > thanks,
> > > jm
> > >
> > >
> > > On Mon, Oct 9, 2017 at 10:13 PM, Ben Pfaff <b...@ovn.org> wrote:
> > >
> > > > OVS doesn't support GTP yet, but I know that there's some ongoing work
> > > > on it.
> > > >
> > > > GRE and VXLAN should be fine.
> > > >
> > > > If you need GTP support, maybe the best thing to do would be to help
> > out
> > > > the folks who are working on it.
> > > >
> > > > On Mon, Oct 09, 2017 at 09:35:42PM +0200, Juraj Markotic wrote:
> > > > > Hello,
> > > > > thanks for feedback.
> > > > > I know OVS can truncate payload and that in can modify mac/IPs in
> > header
> > > > > (i.e. like doing NAT).
> > > > > I also know OVS can deencapsulate GRE (of VXLAN) when packet is
> > arriving
> > > > on
> > > > > tunnel OVS interface (done automatically).
> > > > > But I was not aware that OVS can remove tunnel headers when switching
> > > > > incoming GTP/GRE/VXLAN header and extract inside packet (with
> > totally new
> > > > > src/dst ip) and send it out.
> > > > > Can you share some OVS cli example for such ?
> > > > > we have network packet broker (NPB) with OVS, so if NPB is delivering
> > > > > tunnel packets, it would be great if we could remove tunnel headers
> > > > before
> > > > > delivering it to the (monitoring) tool on outgoing port.
> > > > >
> > > > > thanks,
> > > > > jm
> > > > >
> > > > > On Mon, Oct 9, 2017 at 6:31 PM, Ben Pfaff <b...@ovn.org> wrote:
> > > > >
> > > > > > On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> > > > > > > we would need some functionality on manipulating packets when
> > packet
> > > > is
> > > > > > > exiting outgoing OVS port.
> > > > > > > I.e. some actions could be: change/anonymize mac/IPs for
> > src/dst, or
> > > > > > remove
> > > > > > > some tunnel header (vxlan, gtp, gre), truncate the payload etc.
> > > > > >
> > > > > > OVS has actions for modifying headers and it can decapsulate
> > tunnels
> > > > and
> > > > > > truncate payloads.
> > > > > >
> > > > > > > So, one option can be to write some code than can be attached to
> > OVS
> > > > to
> > > > > > > packet exiting out port (i.e. some lua scripts for manipulation).
> > > > > >
> > > > > > Lua isn't needed.  You can use OpenFlow.
> > > > > >
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVSK flow keeps minimal rate

[Ben Pfaff]

On Mon, Oct 09, 2017 at 11:25:05PM +0200, Mita Cokic wrote:
> I was executing following test case - on 30Mbps link limited OVSK instance
> data was pushed as two TCP flows:
> - Flow A: 200Kbps
> - Flow B: 300Mbps
> 
> I have observed that Flow A bandwidth drops for around 10% but still manages
> to keep constant rate at about 180Kbps.
> 
> When this test case is repeated with Flow A bandwidth increased to 30Mbps,
> both flows start to fluctuate, as expected behavior of congestion avoidance
> algorithm (default, cubic).
> 
> Did anyone experience something like this? Does OVSK tries to keep flows
> alive guaranteeing some minimal throughput?

I don't know what OVSK is.  The following answer is for OVS.

Did you read the documentation and the FAQ?  Some relevant excerpts
below.

   Policing is a simple form of quality-of-service that simply drops pack‐
   ets received in excess of the configured rate. Due to  its  simplicity,
   policing  is  usually  less accurate and less effective than egress QoS
   (which is configured using the QoS and Queue tables).

   Policing is currently implemented on Linux  and  OVS  with  DPDK.  Both
   implementations use a simple ``token bucket’’ approach:

  ·  The  size  of  the  bucket  corresponds to ingress_polic‐
 ing_burst. Initially the bucket is full.

  ·  Whenever a packet is received,  its  size  (converted  to
 tokens)  is compared to the number of tokens currently in
 the bucket. If the required number of tokens  are  avail‐
 able,  they are removed and the packet is forwarded. Oth‐
 erwise, the packet is dropped.

  ·  Whenever it is not full,  the  bucket  is  refilled  with
 tokens at the rate specified by ingress_policing_rate.

   Policing  interacts  badly  with some network protocols, and especially
   with fragmented IP packets. Suppose that there is enough network activ‐
   ity  to  keep  the  bucket  nearly  empty all the time. Then this token
   bucket algorithm will forward a single packet every so often, with  the
   period  depending on packet size and on the configured rate. All of the
   fragments of an IP packets are normally transmitted back-to-back, as  a
   group. In such a situation, therefore, only one of these fragments will
   be forwarded and the rest will be dropped. IP does not provide any  way
   for  the intended recipient to ask for only the remaining fragments. In
   such a case there are two likely possibilities  for  what  will  happen
   next:  either all of the fragments will eventually be retransmitted (as
   TCP will do), in which case the same problem will recur, or the  sender
   will  not realize that its packet has been dropped and data will simply
   be lost (as some UDP-based protocols will do). Either way, it is possi‐
   ble that no forward progress will ever occur.

Q: How do I configure ingress policing?

A: A policing policy can be configured on an interface to drop packets that
arrive at a higher rate than the configured value.  For example, the
following commands will rate-limit traffic that vif1.0 may generate to
10Mbps:

$ ovs-vsctl set interface vif1.0 ingress_policing_rate=1
$ ovs-vsctl set interface vif1.0 ingress_policing_burst=8000

Traffic policing can interact poorly with some network protocols and can
have surprising results.  The "Ingress Policing" section of
ovs-vswitchd.conf.db(5) discusses the issues in greater detail.

Q: I configured QoS, correctly, but my measurements show that it isn't working
as well as I expect.

A: With the Linux kernel, the Open vSwitch implementation of QoS has two
aspects:

- Open vSwitch configures a subset of Linux kernel QoS features, according
  to what is in OVSDB.  It is possible that this code has bugs.  If you
  believe that this is so, then you can configure the Linux traffic control
  (QoS) stack directly with the "tc" program.  If you get better results
  that way, you can send a detailed bug report to b...@openvswitch.org.

  It is certain that Open vSwitch cannot configure every Linux kernel QoS
  feature.  If you need some feature that OVS cannot configure, then you
  can also use "tc" directly (or add that feature to OVS).

- The Open vSwitch implementation of OpenFlow allows flows to be directed
  to particular queues.  This is pretty simple and unlikely to have serious
  bugs at this point.

However, most problems with QoS on Linux are not bugs in Open vSwitch at
all.  They tend to be either configuration errors (please see the earlier
questions in this section) or issues with the traffic control (QoS) stack
in Linux.  The Open vSwitch developers are not experts on Linux traffic
control.  We 

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

[Ben Pfaff]

GRE and tunnels are implemented in terms of ports, so if you send a
packet received on a GRE port to a non-tunnel port, it strips the
header.

On Mon, Oct 09, 2017 at 10:45:10PM +0200, Juraj Markotic wrote:
> I will check on about GTP ongoing activities (I saw some actitvities on
> providing capabilities to match on GTP-C/GTP-U packets).
> maybe dumb question, but any pointer on how to remove GRE header (or VXLAN
> for that matter) when switching packet from IN port to OUT port and switch
> out only internal packet/payload ?
> thanks,
> jm
> 
> 
> On Mon, Oct 9, 2017 at 10:13 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > OVS doesn't support GTP yet, but I know that there's some ongoing work
> > on it.
> >
> > GRE and VXLAN should be fine.
> >
> > If you need GTP support, maybe the best thing to do would be to help out
> > the folks who are working on it.
> >
> > On Mon, Oct 09, 2017 at 09:35:42PM +0200, Juraj Markotic wrote:
> > > Hello,
> > > thanks for feedback.
> > > I know OVS can truncate payload and that in can modify mac/IPs in header
> > > (i.e. like doing NAT).
> > > I also know OVS can deencapsulate GRE (of VXLAN) when packet is arriving
> > on
> > > tunnel OVS interface (done automatically).
> > > But I was not aware that OVS can remove tunnel headers when switching
> > > incoming GTP/GRE/VXLAN header and extract inside packet (with totally new
> > > src/dst ip) and send it out.
> > > Can you share some OVS cli example for such ?
> > > we have network packet broker (NPB) with OVS, so if NPB is delivering
> > > tunnel packets, it would be great if we could remove tunnel headers
> > before
> > > delivering it to the (monitoring) tool on outgoing port.
> > >
> > > thanks,
> > > jm
> > >
> > > On Mon, Oct 9, 2017 at 6:31 PM, Ben Pfaff <b...@ovn.org> wrote:
> > >
> > > > On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> > > > > we would need some functionality on manipulating packets when packet
> > is
> > > > > exiting outgoing OVS port.
> > > > > I.e. some actions could be: change/anonymize mac/IPs for src/dst, or
> > > > remove
> > > > > some tunnel header (vxlan, gtp, gre), truncate the payload etc.
> > > >
> > > > OVS has actions for modifying headers and it can decapsulate tunnels
> > and
> > > > truncate payloads.
> > > >
> > > > > So, one option can be to write some code than can be attached to OVS
> > to
> > > > > packet exiting out port (i.e. some lua scripts for manipulation).
> > > >
> > > > Lua isn't needed.  You can use OpenFlow.
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

[Ben Pfaff]

OVS doesn't support GTP yet, but I know that there's some ongoing work
on it.

GRE and VXLAN should be fine.

If you need GTP support, maybe the best thing to do would be to help out
the folks who are working on it.

On Mon, Oct 09, 2017 at 09:35:42PM +0200, Juraj Markotic wrote:
> Hello,
> thanks for feedback.
> I know OVS can truncate payload and that in can modify mac/IPs in header
> (i.e. like doing NAT).
> I also know OVS can deencapsulate GRE (of VXLAN) when packet is arriving on
> tunnel OVS interface (done automatically).
> But I was not aware that OVS can remove tunnel headers when switching
> incoming GTP/GRE/VXLAN header and extract inside packet (with totally new
> src/dst ip) and send it out.
> Can you share some OVS cli example for such ?
> we have network packet broker (NPB) with OVS, so if NPB is delivering
> tunnel packets, it would be great if we could remove tunnel headers before
> delivering it to the (monitoring) tool on outgoing port.
> 
> thanks,
> jm
> 
> On Mon, Oct 9, 2017 at 6:31 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> > > we would need some functionality on manipulating packets when packet is
> > > exiting outgoing OVS port.
> > > I.e. some actions could be: change/anonymize mac/IPs for src/dst, or
> > remove
> > > some tunnel header (vxlan, gtp, gre), truncate the payload etc.
> >
> > OVS has actions for modifying headers and it can decapsulate tunnels and
> > truncate payloads.
> >
> > > So, one option can be to write some code than can be attached to OVS to
> > > packet exiting out port (i.e. some lua scripts for manipulation).
> >
> > Lua isn't needed.  You can use OpenFlow.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Internal Ports and Queues

[Ben Pfaff]

On Fri, Oct 06, 2017 at 07:24:15PM -0500, Prabhu wrote:
> I am evaluating openvswitch for implementing a load balancing based on Queue
> length.
> 
> I know OVS can set queue to ports attached to the bridge using linux tc
> utility.
> 
> I would like to know whether I can assign queues to Internal ports to
> measure the backlog.Before I split the traffic to two interfaces using group
> select bucket method.

I don't think that internal ports have queues.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

[Ben Pfaff]

On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> we would need some functionality on manipulating packets when packet is
> exiting outgoing OVS port.
> I.e. some actions could be: change/anonymize mac/IPs for src/dst, or remove
> some tunnel header (vxlan, gtp, gre), truncate the payload etc.

OVS has actions for modifying headers and it can decapsulate tunnels and
truncate payloads.

> So, one option can be to write some code than can be attached to OVS to
> packet exiting out port (i.e. some lua scripts for manipulation).

Lua isn't needed.  You can use OpenFlow.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-ofctl vs openflow 1.x vs ?

[Ben Pfaff]

On Sun, Oct 08, 2017 at 11:09:23PM -0300, Raymond Burkholder wrote:
> I've written some openflow controller code to submit openflow line-protocol
> based commands.
> 
> In looking at the ovs-fields document, there appears to be OVS functions
> available which are not available via openflow protocol commands.
> 
> Those extensions seem to be available in ovs-ofctl though.
> 
> Is there an API way of doing things instead of going through ovs-ofctl?  Or
> are the NXM extensions available in one of the OpenFlow versions?  For
> example, I've been programming via OF1.4.1 at this point (found at
> https://benpfaff.org/ofh/openflow-spec1.4.1.h).
> 
> From the ovs-fields document, there is NXM_NX_CONJ_ID (for conjunctive match
> fields), which shows as not being an openflow protocol based function.
> 
> IE, could flow tables be updated via JSON documents, like what is used to
> update the ovsdb?
> 
> Or am I missing something obvious?

I'm not sure what you're looking for here.  OpenFlow *is* the Open
vSwitch API.  You can use all the NXM fields through it, since NXM and
OXM are compatible (OVS introduced NXM then OpenFlow later adopted it
and renamed it OXM).

OpenFlow isn't JSON based so that won't work.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] vswitchd is hanging on service start

[Ben Pfaff]

On Thu, Oct 05, 2017 at 11:37:09PM +, Omar Ramadan wrote:
> vswitchd is blocking when I try starting the service on system boot. Can 
> someone help me make sense of this message:
> 
> 
> vagrant@magma-dev:~$ sudo tail -f /var/log/openvswitch/ovs-vswitchd.log
> 2017-10-05T23:32:07.501Z|00019|ofproto_dpif|INFO|system@ovs-system: Datapath 
> supports ct_orig_tuple
> 2017-10-05T23:32:07.516Z|1|ofproto_dpif_upcall(handler1)|INFO|received 
> packet on unassociated datapath port 0
> 2017-10-05T23:32:07.523Z|00020|bridge|INFO|bridge managed_br0: added 
> interface managed_br0 on port 65534
> 2017-10-05T23:32:08.528Z|1|ovs_rcu(urcu5)|WARN|blocked 1007 ms waiting 
> for main to quiesce
> 2017-10-05T23:32:09.523Z|2|ovs_rcu(urcu5)|WARN|blocked 2002 ms waiting 
> for main to quiesce
> ...

Usually this kind of message means that the thread in question (the main
thread in this case) is not cycling through the main loop in a
reasonable time but blocked somewhere.  If you can get a backtrace of
the main thread (live or from a core dump), it will probably point to
the place it's blocking.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] About side effect of port mirroring

[Ben Pfaff]

On Wed, Oct 04, 2017 at 06:54:39PM +0900, Kurokawa Ryota wrote:
> Hi
> 
> I will use port mirroring.
> I learned how to use port mirroring by looking at the manual. 
> 
> I have one question.
> 
> 「As a side effect, port mirroring causes any packets received on output port 
> to be ignored.」
> 
> What does this mean?
> Does that mean that any packets received on output port will be dropped when 
> they arrive at the switch?

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