On 6/1/22 17:11, Numan Siddique wrote:
On Wed, May 11, 2022 at 2:45 PM Mark Michelson <[email protected]> wrote:
On 5/10/22 12:27, Adrian Moreno wrote:
[...]
Some good alternatives to using the lflow UUID as a datapath
identifier would be
* The value of the OXM_METADATA register.
* The southbound datapath_binding UUID.
If we use any of these identifiers, we would know what datapath
dropped the packet but not what lflow in it's pipeline did it, Right?
OK, I see your point here now. For some reason I was thinking that the
sample() would capture the current OF flow where the sample was sent,
but that's not how it works.
As was discussed before, logical flows can be coalesced if datapath
groups are enabled. So a logical flow UUID is ambiguous when trying to
determine which logical datapath dropped the packet.
One idea would be to implicitly disable logical datapath groups when
drop debugging is enabled. This way, logical flow UUIDs are not
ambiguous. One downside is that the southbound database will become
larger, likely resulting in OVSDB and ovn-controller incurring more
CPU and taking longer to process the data. Since this is an active
debugging scenario, that may not be a problem. The other potential
downside would be if removing logical datapath groups causes the
problem to present itself differently. That could turn a simple issue
into a heisenbug.
Another approach would be to encode data directly into the
ObservationPointID. From what I can tell, the key things you need to
know where a packet was dropped are
* Logical datapath
* OF table
* OF priority
Logical datapaths are 24 bits. I'm not sure what the maximum size for
OF tables are, but with OVN, 8 bits is plenty. Priorities are 16 bits.
Therefore, 48 bits would be necessary to encode all of that. Since the
ObservationPointID is only 32 bits, that makes this idea not work
as-is. You'd have to include another field, potentially.
If the logical datapaths are only 24 bits I think we can squeeze the
information in. What we can specify in the sample action is:
ObservationPointID: 32bit
ObservationDomainID: 32bit
Let's say for each IPFIX "application" that OVN might want to implement
in the future (drop-debugging is just one of them) we define a
"base_obs_domain_id" where:
0 < base_obs_domain_id < 256
and we make the controller insert:
obs_domain_id = (base_obs_domain_id << 24 | logical_datapath)
In addition, for ovn-debug we use:
obs_point_id = lflow_uuid
This would allow for 254 different non-overlaping uses of IPFIX by OVN
plus 16Mi observation_domain_ids for external users to use
(base_domain_id = 0).
For drop debugging we'll always know the logical flow that caused the
drop and the logical datapath it belongs to.
Would this work?
Where can I find those unique 24bits that identify the datapath? Are
they available when on action encoding (i.e: through struct
ovnact_encode_params)?
That sounds like it should work. The 24 bits that identify the datapath
are the "tunnel_key" column on the datapath_binding in the southbound
database. This is the same value we put in the OXM_METADATA register,
and it's the same value we encode in the GENEVE metadata on tunnels.
Thanks for the patience and guidance.
I'm sorry for being late in taking a look at this discussion.
Just checking if this series is going to be respinned as a formal
patch series with the inputs provided by Mark ?
Or if further discussion is required ?
Yes, I'll respin this as proper patch series.
I don't know much about IPFIX. Is it possible to define the metadata
(and perhaps other ovs registers) into the ipfix template record ?
(Sorry if its a stupid question).
Unfortunately, it does not. We can only "hardcode" stuff in the action itself in
the fields described in ovs-actions(7):
https://www.mankier.com/7/ovs-actions#Other_Actions-The_sample_action
Thanks
Numan
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
--
Adrián Moreno
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
