Re: [ovs-discuss] Way of handling rules at the OVS flow-table is there any time order?

[Ben Pfaff]

On Fri, Nov 20, 2020 at 10:25:30AM +0100, Jordi Baranda wrote:
> On 19/11/2020 18:35, Ben Pfaff wrote:
> > On Thu, Nov 19, 2020 at 12:20:01PM +0100, Jordi Baranda wrote:
> > > If I use break-before-make, there is no problem because I replace the 
> > > rules
> > > and that is. However for the make-before-break approach, I foresee that 
> > > there
> > > will be some flow rules with the same match fields but different action
> > > fields. (e.g, t0: in_port: 3 -> out_port: 2 vs t1: in_port: 3 -> 
> > > out_port:4,
> > > where t0 means time0 and t1 means time1 and t1 > t0 (older time instant) 
> > > ).  I
> > > know I could handle that with priorities but I think this may add further
> > > complexity to the SDN controller app.
> > I don't think this makes any sense.  You cannot have two flows in a
> > table with the same match fields and the same priority.  Those are the
> > same flow, and it has either one set of actions or another.
> Yes, I understand. These entries will coexist for short time due to the
> make-before-break approach. I will install the "new rule" with the same
> match and different action and then remove the "old rule". My question as
> you well described bellow is what happens while they coexist.

This is like saying that you're going to have two files with the same
name in a directory for a brief time.  Doesn't work.

> > > I am wondering if I can skip this treatment at the SDN controller app 
> > > making
> > > use of how OVS applies/evaluates rules in the flow table. More 
> > > specifically,
> > > rules in the flow table of OVS (for the same priority) are evaluated in 
> > > any
> > > time order? That is, OVS is considering "t1 rule" (which is more recent 
> > > than
> > > the one of t0) before than "t0 rule"  (however, t0 rule will be erased
> > > afterwards)? Or are the flow-rules in the flow table ordered/evaluated
> > > "randomly"? Additionally, has this changed through the OVS versions?
> > I'm not sure I understand the question.  Skipping by the problem above,
> > let me rephrase my understanding of it in another way, and you can
> > correct me if I get it wrong.  I think you are saying, if a given packet
> > has two "best match" flows at the same priority, will OVS choose the one
> > added later by preference?  No, OVS doesn't work that way; it has never
> > used the order in which flows are added as an input into the
> > classification process.
> 
> Yes, the problem is as you described. While the rules coexists, which one
> will be applied? According to what I read, I suppose OVS checks the rules in
> the flow table and applies the first one making match. However, as I
> understand, OVS is not applying "any given order" to evaluate the rules in
> the flow-table, it could be that sometimes applies one rule and other time
> applies the other rule. Is my understanding correct? I have found a thread
> in stackoverflow asking about the same issue 
> 
> that I am presenting. They say OVS will match the new rule, but maybe it was
> casual. Is the behaviour that they see consistent in OVS?

OVS doesn't guarantee any behavior here.  It probably changes from one
version to the next, or maybe even from one run to the next.

I suggest using transactions to replace the contents of the flow table
atomically.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] [ovn] Broken ovs localport flow for ovnmeta namespaces created by neutron

[Krzysztof Klimonda]

Hi,

Doing some tempest runs on our pre-prod environment (stable/ussuri with ovn 
20.06.2 release) I've noticed that some network connectivity tests were failing 
randomly. I've reproduced that by conitnously rescuing and unrescuing instance 
- network connectivity from and to VM works in general (dhcp is fine, access 
from outside is fine), however VM has no access to its metadata server (via 
169.254.169.254 ip address). Tracing packet from VM to metadata via:

8<8<8<
ovs-appctl ofproto/trace br-int 
in_port=tapa489d406-91,dl_src=fa:16:3e:2c:b0:fd,dl_dst=fa:16:3e:8b:b5:39
8<8<8<

ends with

8<8<8<
65. reg15=0x1,metadata=0x97e, priority 100, cookie 0x15ec4875
output:1187
 >> Nonexistent output port
8<8<8<

And I can verify that there is no flow for the actual ovnmeta tap interface 
(tap67731b0a-c0):

8<8<8<
# docker exec -it openvswitch_vswitchd ovs-ofctl dump-flows br-int |grep -E 
output:'("tap67731b0a-c0"|1187)'
 cookie=0x15ec4875, duration=1868.378s, table=65, n_packets=524, n_bytes=40856, 
priority=100,reg15=0x1,metadata=0x97e actions=output:1187
#
8<8<8<

>From ovs-vswitchd.log it seems the interface tap67731b0a-c0 was added with 
>index 1187, then deleted, and re-added with index 1189 - that's probably due 
>to the fact that that is the only VM in that network and I'm constantly hard 
>rebooting it via rescue/unrescue:

8<8<8<
2020-11-20T11:41:18.347Z|08043|bridge|INFO|bridge br-int: added interface 
tap67731b0a-c0 on port 1187
2020-11-20T11:41:30.813Z|08044|bridge|INFO|bridge br-int: deleted interface 
tapa489d406-91 on port 1186
2020-11-20T11:41:30.816Z|08045|bridge|WARN|could not open network device 
tapa489d406-91 (No such device)
2020-11-20T11:41:31.040Z|08046|bridge|INFO|bridge br-int: deleted interface 
tap67731b0a-c0 on port 1187
2020-11-20T11:41:31.044Z|08047|bridge|WARN|could not open network device 
tapa489d406-91 (No such device)
2020-11-20T11:41:31.050Z|08048|bridge|WARN|could not open network device 
tapa489d406-91 (No such device)
2020-11-20T11:41:31.235Z|08049|connmgr|INFO|br-int<->unix#31: 2069 flow_mods in 
the last 43 s (858 adds, 814 deletes, 397 modifications)
2020-11-20T11:41:33.057Z|08050|bridge|INFO|bridge br-int: added interface 
tapa489d406-91 on port 1188
2020-11-20T11:41:33.582Z|08051|bridge|INFO|bridge br-int: added interface 
tap67731b0a-c0 on port 1189
2020-11-20T11:42:31.235Z|08052|connmgr|INFO|br-int<->unix#31: 168 flow_mods in 
the 2 s starting 59 s ago (114 adds, 10 deletes, 44 modifications) 
8<8<8<

Once I restart ovn-controller it recalculates local ovs flows and the problem 
is fixed so I'm assuming it's a local problem and not related to NB and SB 
databases.

-- 
  Krzysztof Klimonda
  kklimo...@syntaxhighlighted.com
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Way of handling rules at the OVS flow-table is there any time order?

[Jordi Baranda]

Hi Ben,

Thank you very much for your answers.  I have some comments that you can 
find inline.


Again, thank you very much for your time and attention.

Regards,

Jordi

On 19/11/2020 18:35, Ben Pfaff wrote:

On Thu, Nov 19, 2020 at 12:20:01PM +0100, Jordi Baranda wrote:

If I use break-before-make, there is no problem because I replace the rules
and that is. However for the make-before-break approach, I foresee that there
will be some flow rules with the same match fields but different action
fields. (e.g, t0: in_port: 3 -> out_port: 2 vs t1: in_port: 3 -> out_port:4,
where t0 means time0 and t1 means time1 and t1 > t0 (older time instant) ).  I
know I could handle that with priorities but I think this may add further
complexity to the SDN controller app.

I don't think this makes any sense.  You cannot have two flows in a
table with the same match fields and the same priority.  Those are the
same flow, and it has either one set of actions or another.
Yes, I understand. These entries will coexist for short time due to the 
make-before-break approach. I will install the "new rule" with the same 
match and different action and then remove the "old rule". My question 
as you well described bellow is what happens while they coexist.



I am wondering if I can skip this treatment at the SDN controller app making
use of how OVS applies/evaluates rules in the flow table. More specifically,
rules in the flow table of OVS (for the same priority) are evaluated in any
time order? That is, OVS is considering "t1 rule" (which is more recent than
the one of t0) before than "t0 rule"  (however, t0 rule will be erased
afterwards)? Or are the flow-rules in the flow table ordered/evaluated
"randomly"? Additionally, has this changed through the OVS versions?

I'm not sure I understand the question.  Skipping by the problem above,
let me rephrase my understanding of it in another way, and you can
correct me if I get it wrong.  I think you are saying, if a given packet
has two "best match" flows at the same priority, will OVS choose the one
added later by preference?  No, OVS doesn't work that way; it has never
used the order in which flows are added as an input into the
classification process.


Yes, the problem is as you described. While the rules coexists, which 
one will be applied? According to what I read, I suppose OVS checks the 
rules in the flow table and applies the first one making match. However, 
as I understand, OVS is not applying "any given order" to evaluate the 
rules in the flow-table, it could be that sometimes applies one rule and 
other time applies the other rule. Is my understanding correct? I have 
found a thread in stackoverflow asking about the same issue 
 
that I am presenting. They say OVS will match the new rule, but maybe it 
was casual. Is the behaviour that they see consistent in OVS?


--
CTTC Logo







*Jorge Baranda*
Senior Researcher, MsC
jorge.bara...@cttc.cat 




Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7 - Building B4
08860 - Castelldefels
Tel.: +34 93 645 29 00

_DATA PROTECTION INFORMATION. Data controller: CENTRE TECNOLOGIC DE 
TELECOMUNICACIONS DE CATALUNYA (G62616586):_


We inform you that your identification data and the data contained in 
the emails and attached files can be incorporated into our databases, in 
order to maintain professional and / or commercial relationships, and 
that it will be preserved throughout the relationship. According to the 
current regulations, you can exercise your right to access, 
rectification, erasure, restriction of processing, to portability and to 
object by sending an email to d...@cttc.cat.
This message and any attached document, where appropriate, may be 
confidential and intended for the original recipient only.



L'informem que les seves dades identificatives i les compreses als 
correus electrònics i fitxers adjunts poden ser incorporades a les 
nostres bases de dades amb la finalitat de mantenir relacions 
professionals i/o comercials i, que seran conservades mentre es 
mantingui aquesta relació. Si ho desitja, pot exercir el seu dret 
d'accés, rectificació, supressió, limitació del tractament, portabilitat 
i objecció enviant un correu electrònic a d...@cttc.cat.
Aquest missatge i qualsevol document adjunt, en el seu cas, pot ser 
confidencial i destinat únicament a la persona o entitat a qui s'hagi 
enviat.


Before printing this e-mail or attachments, be sure it is necessary. It 
is in our hands to protect the environment.


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