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

[José Miguel Guzmán]

Hello

I need to change the range of source ports for VXLAN tunnels.

Although I tried with set dst_port to 2000
# ovs-vsctl add-port br-ovs vxlan3 -- set interface vxlan3 type=vxlan
options:remote_ip=192.168.111.203 options:dst_port=2

and egress port range to 2-20001
# ovs-appctl tnl/egress_port_range 2 20001
# ovs-appctl tnl/egress_port_range
Tunnel UDP source port range: 2-20001

I continue seeing VXLAN packets are picking random source ports within the
default port range (dst ports are correctly changed):

04:35:05.979474 IP 192.168.111.202.40041 > 192.168.111.203.2: UDP,
length 89
04:35:05.979477 IP 192.168.111.202.55569 > 192.168.111.203.2: UDP,
length 89
04:35:09.079814 IP 192.168.111.202.40041 > 192.168.111.203.2: UDP,
length 89
04:35:09.079817 IP 192.168.111.202.55569 > 192.168.111.203.2: UDP,
length 89
04:35:12.179227 IP 192.168.111.202.40041 > 192.168.111.203.2: UDP,
length 89
04:35:12.179230 IP 192.168.111.202.55569 > 192.168.111.203.2: UDP,
length 89
04:35:15.279437 IP 192.168.111.202.40041 > 192.168.111.203.2: UDP,
length 89
04:35:15.279440 IP 192.168.111.202.55569 > 192.168.111.203.2: UDP,
length 89

When looking to the vxlan interface created, srcport is not set

# ip -d link show vxlan_sys_2
32: vxlan_sys_2:  mtu 65485 qdisc
noqueue master ovs-system state UNKNOWN mode DEFAULT group default qlen 1000
link/ether ae:7e:0f:f1:b0:0a brd ff:ff:ff:ff:ff:ff promiscuity 1
vxlan id 0 *srcport 0 0* dstport 2 nolearning ageing 300 external
openvswitch_slave addrgenmode eui64

Am I doing something wrong?
Uting ovs 2.5.0 on Linux 4.4.91

Thanks a lot!!
JM
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Ben Pfaff]

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

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

> > > Here's some ideas:
> > >
> > > # 1. A new map column
> > >
> > > We could add a "map" type column called "ports" in the Address_Set
> > > table that would look like this in the database:
> > >
> > > "Address_Set": {
> > >   "ports": {"port-1-name": {"ipv4_addresses": [...],
> > >  "ipv6_addresses": [...}}
> > >   ...
> > > }
> >
> > This particular solution seems to me like it solves a very specific
> > problem.  I'd rather solve a more general problem if we can.
> >
> > > # 2: Add a new way to populate the address set:
> > >
> > > Instead of directly populating the addresses in an address set where
> > > the port relationship isn't clear, we could add two list of ports
> > > references (one for each IP version) and have the addresses
> > > automatically populated.
> > >
> > > For example:
> > >
> > > "Address_Set": {
> > >   "columns": {
> > > "ipv4_ports": {"type": {"key": {"type": "uuid",
> > > "refTable": "Logical_Switch_Port",
> > > "refType": "weak"},
> > > "min": 0,
> > > "max": "unlimited"}}
> > > "ipv6_ports": {"type": {"key": {"type": "uuid",
> > > "refTable": "Logical_Switch_Port",
> > > "refType": "weak"},
> > > "min": 0,
> > > "max": "unlimited"}}
> > >  ...
> > > }
> > >
> > > The problem here is that we would pull all addresses from those ports
> > > into the address set.
> > >
> > > The good part is that since it's a weak reference, deleting a port
> > > would automatically remove it from the address set.
> >
> > This is creative and I appreciate it.  It also seems very specific to
> > this particular problem.
> >
> #1 and #2 make the assumption that all addresses in a set belong to a
> lport, which is not always true (it may be true in 

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

[Daniel Alvarez Sanchez]

On Wed, Feb 14, 2018 at 9:34 PM, Han Zhou  wrote:

>
>
> On Wed, Feb 14, 2018 at 9:45 AM, Ben Pfaff  wrote:
> >
> > On Wed, Feb 14, 2018 at 11:27:11AM +0100, Daniel Alvarez Sanchez wrote:
> > > Thanks for your inputs. I need to look more carefully into the patch
> you
> > > submitted but it looks like, at least, we'll be reducing the number of
> > > calls to Datum.__cmp__ which should be good.
> >
> > Thanks.  Please do take a look.  It's a micro-optimization but maybe
> > it'll help?
> >
> > > I probably didn't explain it very well. Right now we have N processes
> > > for Neutron server (in every node). Each of those opens a connection
> > > to NB db and they subscribe to updates from certain tables. Each time
> > > a change happens, ovsdb-server will send N update2 messages that has
> > > to be processed in this "expensive" way by each of those N
> > > processes. My proposal (yet to be refined) would be to now open N+1
> > > connections to ovsdb-server and only subscribe to notifications from 1
> > > of those. So every time a new change happens, ovsdb-server will send 1
> > > update2 message. This message will be processed (using Py IDL as we do
> > > now) and once processed, send it (mcast maybe?) to the rest N
> > > processes. This msg could be simply a Python object serialized and
> > > we'd be saving all this Datum, Atom, etc. processing by doing it just
> > > once.
> >
> Daniel, I understand that the update2 messages sending would consume NB
> ovsdb-server CPU and processing those update would consume neutron server
> process CPU. However, are we sure it is the bottleneck for port creation?
>
> From ovsdb-server point of view, sending updates to tens of clients should
> not be the bottleneck, considering that we have a lot more clients on HVs
> for SB ovsdb-server.
>
> From clients point of view, I think it is more of memory overhead than
> CPU, and it also depends on how many neutron processes are running on the
> same node. I didn't find neutron process CPU in your charts. I am hesitate
> for such big change before we are clear about the bottleneck. The chart of
> port creation time is very nice, but do we know which part of code
> contributed to the linear growth? Do we have profiling for the time spent
> in ovn_client.add_acls()?
>

Here we are [0]. We see some spikes which are larger as the amount of ports
increases
but looks like the actual bottleneck is going to be when we're actually
commiting the
transaction [1]. I'll dig further though.

[0 https://imgur.com/a/TmwbC
[1]
https://github.com/openvswitch/ovs/blob/master/python/ovs/db/idl.py#L1158

>
> > OK.  It's an optimization that does the work in one place rather than N
> > places, so definitely a win from a CPU cost point of view, but it trades
> > performance for increased complexity.  It sounds like performance is
> > really important so maybe the increased complexity is a fair trade.
> >
> > We might also be able to improve performance by using native code for
> > some of the work.  Were these tests done with the native code JSON
> > parser that comes with OVS?  It is dramatically faster than the Python
> > code.
> >
> > > On Tue, Feb 13, 2018 at 8:32 PM, Ben Pfaff  wrote:
> > >
> > > > Can you sketch the rows that are being inserted or modified when a
> port
> > > > is added?  I would expect something like this as a minimum:
> > > >
> > > > * Insert one Logical_Switch_Port row.
> > > >
> > > > * Add pointer to Logical_Switch_Port to ports column in one
> row
> > > >   in Logical_Switch.
> > > >
> > > > In addition it sounds like currently we're seeing:
> > > >
> > > > * Add one ACL row per security group rule.
> > > >
> > > > * Add pointers to ACL rows to acls column in one row in
> > > >   Logical_Switch.
> > > >
> > > This is what happens when we create a port in OpenStack (without
> > > binding it) which belongs to a SG which allows ICMP and SSH traffic
> > > and drops the rest [0]
> > >
> > > Basically, you were right and only thing missing was adding the new
> > > address to the Address_Set table.
> >
> > OK.
> >
> > It sounds like the real scaling problem here is that for R security
> > group rules and P ports, we have R*P rows in the ACL table.  Is that
> > correct?  Should we aim to solve that problem?
>
> I think this might be the most valuable point to optimize for the
> create_port scenario from Neutron.
> I remember there was a patch for ACL group in OVN, so that instead of R*P
> rows we will have only R + P rows, but didn't see it went through.
> Is this also a good use case of conjuncture?
>
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Han Zhou]

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

> > Here's some ideas:
> >
> > # 1. A new map column
> >
> > We could add a "map" type column called "ports" in the Address_Set
> > table that would look like this in the database:
> >
> > "Address_Set": {
> >   "ports": {"port-1-name": {"ipv4_addresses": [...],
> >  "ipv6_addresses": [...}}
> >   ...
> > }
>
> This particular solution seems to me like it solves a very specific
> problem.  I'd rather solve a more general problem if we can.
>
> > # 2: Add a new way to populate the address set:
> >
> > Instead of directly populating the addresses in an address set where
> > the port relationship isn't clear, we could add two list of ports
> > references (one for each IP version) and have the addresses
> > automatically populated.
> >
> > For example:
> >
> > "Address_Set": {
> >   "columns": {
> > "ipv4_ports": {"type": {"key": {"type": "uuid",
> > "refTable": "Logical_Switch_Port",
> > "refType": "weak"},
> > "min": 0,
> > "max": "unlimited"}}
> > "ipv6_ports": {"type": {"key": {"type": "uuid",
> > "refTable": "Logical_Switch_Port",
> > "refType": "weak"},
> > "min": 0,
> > "max": "unlimited"}}
> >  ...
> > }
> >
> > The problem here is that we would pull all addresses from those ports
> > into the address set.
> >
> > The good part is that since it's a weak reference, deleting a port
> > would automatically remove it from the address set.
>
> This is creative and I appreciate it.  It also seems very specific to
> this particular problem.
>
#1 and #2 make the assumption that all addresses in a set belong to a
lport, which is not always true (it may be true in current Neutron,
though). We should not prevent user from using address set without creating
lport for the addresses.

> > # 3: Allow duplicated addresses in the list
> >
> > If the above options sounds too complicated, maybe we could keep the
> > idea of this email of creating a "Macro_Set" that could be used for
> > both ports and addresses types [0]. But, when the type is set to
> > "address" we could allow duplicated items in the list of elements that
> > way we 

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

[Ben Pfaff]

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

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

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

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

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

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

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

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

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

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

Re: [ovs-discuss] ovs-vswitchd 100% CPU in OVN scale test

[Mark Michelson]

On 02/08/2018 07:55 PM, Han Zhou wrote:



On Wed, Feb 7, 2018 at 12:47 PM, Han Zhou > wrote:

 >
 > When doing scale testing for OVN (using 
https://github.com/openvswitch/ovn-scale-test), we had some interesting 
findings, and need some help here.

 >
 > We ran the test "create and bind lports" against branch 2.9 and 
branch 2.6, and we found that 2.6 was must faster. With some analysis, 
we found out the reason is not because of OVN gets slower in 2.9, but 
because the bottleneck of this test in branch 2.9 is ovs-vswitchd.

 >
 > The testing was run in an environment with 20 farm nodes, each has 50 
sandbox HVs (I will just mention them as HVs in short). Before the test, 
there are already 9500 lports bound in 950 HVs on 19 farm nodes. The 
test run against the last farm node to bind the lport on the 50 HVs 
there. The steps in the test scenario are:

 >
 > 1. Create 5 new LSs in NB (so that the LSs will not be shared with 
any of HVs on other farm nodes)

 > 2. create 100 lports in NB on a LS
 > 3. bind these lports on HVs, 2 for each HV. They are bound 
sequentially on each HV, and for each HV the 2 ports are bound using one 
command together: ovs-vsctl add-port  -- set Interface 
external-ids:...  -- add-port  -- set Interface external-ids:... 
(the script didn't set type to internal, but I hope it is not an issue 
for this test).
 > 4. wait the port stated changed to up in NB for all the 100 lports 
(with a single ovn-nbctl command)

 >
 > These steps are repeated for 5 times, one for each LS. So in the end 
we got 500 more lports created and bound (the total scale is then 1k HVs 
and 10k lports).

 >
 > When running with 2.6, the ovn-controllers were taking most of the 
CPU time. However, with 2.9, the CPU of ovn-controllers spikes but there 
is always ovs-vswitchd on the top with 100% CPU. It means the 
ovs-vswitchd is the bottleneck in this testing. There is only one 
ovs-vswitchd with 100% at the same time and different ovs-vswitchd will 
spike one after another, since the ports are bound sequentially on each 
HV. From the rally log, each 2 ports binding takes around 4 - 5 seconds. 
This is just the ovs-vsctl command execution time. The 100% CPU of 
ovs-vswitchd explains the slowness.

 >
 > So, based on this result, we can not using the total time to evaluate 
the efficiency of OVN, instead we can evaluate by CPU cost of 
ovn-controller processes. In fact, 2.9 ovn-controller costs around 70% 
less CPU than 2.6, which I think is due to some optimization we made 
earlier. (With my work-in-progress patch it saves much more, and I will 
post later as RFC).

 >
 > However, I cannot explain why ovs-vswitchd is getting slower than 2.6 
when doing port-binding. We need expert suggestions here, for what could 
be the possible reason of this slowness. We can do more testing with 
different versions between 2.6 and 2.9 to find out related change, but 
with some pointers it might save some effort. Below are some logs of 
ovs-vswitchd when port binding is happening:

 >
 > ==
 > 2018-02-07T00:12:54.558Z|01767|bridge|INFO|bridge br-int: added 
interface lport_bc65cd_QFOU3v on port 1028
 > 2018-02-07T00:12:55.629Z|01768|timeval|WARN|Unreasonably long 1112ms 
poll interval (1016ms user, 4ms system)

 > 2018-02-07T00:12:55.629Z|01769|timeval|WARN|faults: 336 minor, 0 major
 > 2018-02-07T00:12:55.629Z|01770|timeval|WARN|context switches: 0 
voluntary, 13 involuntary
 > 2018-02-07T00:12:55.629Z|01771|coverage|INFO|Event coverage, avg rate 
over last: 5 seconds, last minute, last hour,  hash=b256889c:
 > 2018-02-07T00:12:55.629Z|01772|coverage|INFO|bridge_reconfigure   
   0.0/sec     0.000/sec        0.0056/sec   total: 29
 > 2018-02-07T00:12:55.629Z|01773|coverage|INFO|ofproto_flush   
    0.0/sec     0.000/sec        0./sec   total: 1
 > 2018-02-07T00:12:55.629Z|01774|coverage|INFO|ofproto_packet_out   
   0.0/sec     0.000/sec        0.0111/sec   total: 90
 > 2018-02-07T00:12:55.629Z|01775|coverage|INFO|ofproto_recv_openflow   
    0.2/sec     0.033/sec        0.4858/sec   total: 6673
 > 2018-02-07T00:12:55.629Z|01776|coverage|INFO|ofproto_update_port 
    0.0/sec     0.000/sec        5.5883/sec   total: 28258
 > 2018-02-07T00:12:55.629Z|01777|coverage|INFO|rev_reconfigure 
    0.0/sec     0.000/sec        0.0056/sec   total: 32
 > 2018-02-07T00:12:55.629Z|01778|coverage|INFO|rev_port_toggled 
   0.0/sec     0.000/sec        0.0011/sec   total: 6
 > 2018-02-07T00:12:55.629Z|01779|coverage|INFO|rev_flow_table   
   0.0/sec     0.000/sec        0.0078/sec   total: 124
 > 2018-02-07T00:12:55.629Z|01780|coverage|INFO|rev_mac_learning 
   0.0/sec     0.000/sec        0.0036/sec   total: 13
 > 2018-02-07T00:12:55.629Z|01781|coverage|INFO|xlate_actions   
    0.0/sec     0.000/sec        0.0111/sec   total: 90
 > 2018-02-07T00:12:55.629Z|01782|coverage|INFO|ccmap_expand 
   0.0/sec     

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

[Lucas Alvares Gomes]

Hi all,

We currently have a problem with Address_Set in networking-ovn (and
potentially other technologies using OVN as backend) which *maybe*
could be fixed together with this idea of a new "port set" (a.k.a
macro set).

The problem is bit tricky but it shows as a race condition between
creating and deleting ports in Neutron. That is, deleting a port in
Neutron will result in the IP address of that port to be removed from
an address set, but at the same time, if another request to create a
port overtaking the same IP address of the port being deleted is
issued, depending on which order things are committed it could result
in the address set to not contain the new port IP address.

Here's a bug ticket describing the problem in more detail:
https://bugs.launchpad.net/networking-ovn/+bug/1611852

The reason why it happens is because we don't have a direct
relationship between the addresses in an address set and the ports
that those addresses belongs to. So, if we create this relation we
might end up having both ports and addresses present in the
Address_Set table which then can be used to fix both of our problems.

Here's some ideas:

# 1. A new map column

We could add a "map" type column called "ports" in the Address_Set
table that would look like this in the database:

"Address_Set": {
  "ports": {"port-1-name": {"ipv4_addresses": [...],
 "ipv6_addresses": [...}}
  ...
}

# 2: Add a new way to populate the address set:

Instead of directly populating the addresses in an address set where
the port relationship isn't clear, we could add two list of ports
references (one for each IP version) and have the addresses
automatically populated.

For example:

"Address_Set": {
  "columns": {
"ipv4_ports": {"type": {"key": {"type": "uuid",
"refTable": "Logical_Switch_Port",
"refType": "weak"},
"min": 0,
"max": "unlimited"}}
"ipv6_ports": {"type": {"key": {"type": "uuid",
"refTable": "Logical_Switch_Port",
"refType": "weak"},
"min": 0,
"max": "unlimited"}}
 ...
}

The problem here is that we would pull all addresses from those ports
into the address set.

The good part is that since it's a weak reference, deleting a port
would automatically remove it from the address set.

# 3: Allow duplicated addresses in the list

If the above options sounds too complicated, maybe we could keep the
idea of this email of creating a "Macro_Set" that could be used for
both ports and addresses types [0]. But, when the type is set to
"address" we could allow duplicated items in the list of elements that
way we won't have a problem if one transaction removes one duplicated
element in the list.

[0] https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/077118.html

Any more ideas?

Cheers,
Lucas

On Thu, Feb 15, 2018 at 12:04 AM, Ben Pfaff  wrote:
> On Thu, Feb 15, 2018 at 12:36:35AM +0100, Daniel Alvarez Sanchez wrote:
>> If we would have the Port_Set we could simply write the match part as
>> "outport == $security_group1 && ip4 && ip4.src == 0.0.0.0/0 && tcp &&
>> tcp.dst == 22"
>> and reduce the number of ACLs to 1 per security group rule instead of 1 per
>> security
>> group rule per port as it is right now. As you can see, we're referencing
>> the relevant security group rule in the CMS through the
>> neutron:security_group_rule_id
>> key in the external_ids column so we would reduce all ACLs which correspond
>> to
>> the same SG rule to just 1.
>
> OK, that matches up with what Han says.  Han is going to rebase the
> "port set" patches, so I think we'll have a solution for this soon after
> that.
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OF Metering in ovsswitch

[Ben Pfaff]

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

The FAQ says:

Q: Does Open vSwitch support OpenFlow meters?

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

[ovs-discuss] OF Metering in ovsswitch

[AKSHAYA BALAN]

Hi,

We are trying to explore openflow metering in openvswitch. Most of the
available links in internet figured that metering is not supported in ovs.
But ovs-ofctl have add-meter command. Kindly guide us on how we can use it

We are using ovs switch version 2.5 and openflow version from 10 to 13.
When we tried to use this add-meter command,  we got some error related to
openflow version , which is attached with this mail.

Kindly help us to resolve this issue.
Thanks in advance
Regards,
Akshaya Balan
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss