| Message ID | 20221018155936.1394396-1-amorenoz@redhat.com |
|---|---|
| Headers | show |
| Series | ACL Sampling using per-flow IPFIX | expand |
On Tue, Oct 18, 2022 at 12:00 PM Adrian Moreno <amorenoz@redhat.com> wrote: > > Based on the introduction of the OVN "sample" action (still WIP) [1], > the proposal of this RFC is to use per-flow IPFIX sampling to increase > visibility on ACLs. > > The idea of ACL sampling is very similar to the already existing ACL > logging whith the following key differences: > > - Using IPFIX sampling collects header information of the actual packet > that was dropped / accepted by the ACL. This information is key to > debug an issue or understand the traffic profile that traverses the > ACLs. > > - With ACL logging, the information goes to the ovn-controller, > adding pressure to it. Using IPFIX sampling can offload the > ovn-controller by sending samples to external IPFIX collectors. > > - Using the sample action, we don't need to rely on a meter to limit the > amount of data we process since we have the sampling rate/probability. > > - Using IPFIX as standard format makes the solution interoperable so > it's possible to combine with other IPFIX sources to build > comprehensive observability tools. > > This RFC includes a prototype implementation based on the creation of a > new NBDB table "Sample" and a reference to it from the ACL table. This > would allow the use of per-flow IPFIX sampling to add visibility to > other areas of OVN as the needs arise. > > [1] > https://patchwork.ozlabs.org/project/ovn/patch/20221017131403.563877-2-amorenoz@redhat.com/ > > > Adrian Moreno (2): > northd: add ACL Sampling > ovn-nbctl: add sample to acl-add Hi Adrian, Do you plan to submit formal patches ? Or you're expecting any feedback on this series before submitting formally ? If so, I can take a look at the rfc patches. Thanks Numan > > northd/northd.c | 31 ++++++++++++++++++++++++++++++- > ovn-nb.ovsschema | 23 ++++++++++++++++++++++- > ovn-nb.xml | 31 +++++++++++++++++++++++++++++++ > utilities/ovn-nbctl.8.xml | 7 ++++++- > utilities/ovn-nbctl.c | 20 +++++++++++++++++++- > 5 files changed, 108 insertions(+), 4 deletions(-) > > -- > 2.37.3 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >
On 3/17/23 20:59, Numan Siddique wrote: > On Tue, Oct 18, 2022 at 12:00 PM Adrian Moreno <amorenoz@redhat.com> wrote: >> >> Based on the introduction of the OVN "sample" action (still WIP) [1], >> the proposal of this RFC is to use per-flow IPFIX sampling to increase >> visibility on ACLs. >> >> The idea of ACL sampling is very similar to the already existing ACL >> logging whith the following key differences: >> >> - Using IPFIX sampling collects header information of the actual packet >> that was dropped / accepted by the ACL. This information is key to >> debug an issue or understand the traffic profile that traverses the >> ACLs. >> >> - With ACL logging, the information goes to the ovn-controller, >> adding pressure to it. Using IPFIX sampling can offload the >> ovn-controller by sending samples to external IPFIX collectors. >> >> - Using the sample action, we don't need to rely on a meter to limit the >> amount of data we process since we have the sampling rate/probability. >> >> - Using IPFIX as standard format makes the solution interoperable so >> it's possible to combine with other IPFIX sources to build >> comprehensive observability tools. >> >> This RFC includes a prototype implementation based on the creation of a >> new NBDB table "Sample" and a reference to it from the ACL table. This >> would allow the use of per-flow IPFIX sampling to add visibility to >> other areas of OVN as the needs arise. >> >> [1] >> https://patchwork.ozlabs.org/project/ovn/patch/20221017131403.563877-2-amorenoz@redhat.com/ >> >> >> Adrian Moreno (2): >> northd: add ACL Sampling >> ovn-nbctl: add sample to acl-add > > Hi Adrian, > > Do you plan to submit formal patches ? Or you're expecting any > feedback on this series before submitting formally ? > > If so, I can take a look at the rfc patches. > Hi Numan, I am planning to do some performance benchmarking and add it to the formal patch but I would love to get some general feedback on the topic. Whether the approach seems sane (adding sample actions in ACL lflows), whether the general NBDB API is going in the proper direction or if there is some pitfall I'm ignoring. Of course I'm not asking for a full review but a general go/no-go would be nice. Thanks, Adrián > Thanks > Numan > >> >> northd/northd.c | 31 ++++++++++++++++++++++++++++++- >> ovn-nb.ovsschema | 23 ++++++++++++++++++++++- >> ovn-nb.xml | 31 +++++++++++++++++++++++++++++++ >> utilities/ovn-nbctl.8.xml | 7 ++++++- >> utilities/ovn-nbctl.c | 20 +++++++++++++++++++- >> 5 files changed, 108 insertions(+), 4 deletions(-) >> >> -- >> 2.37.3 >> >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> >
On 3/21/23 10:48, Adrian Moreno wrote: > > > On 3/17/23 20:59, Numan Siddique wrote: >> On Tue, Oct 18, 2022 at 12:00 PM Adrian Moreno <amorenoz@redhat.com> >> wrote: >>> >>> Based on the introduction of the OVN "sample" action (still WIP) [1], >>> the proposal of this RFC is to use per-flow IPFIX sampling to increase >>> visibility on ACLs. >>> >>> The idea of ACL sampling is very similar to the already existing ACL >>> logging whith the following key differences: >>> >>> - Using IPFIX sampling collects header information of the actual packet >>> that was dropped / accepted by the ACL. This information is key to >>> debug an issue or understand the traffic profile that traverses the >>> ACLs. >>> >>> - With ACL logging, the information goes to the ovn-controller, >>> adding pressure to it. Using IPFIX sampling can offload the >>> ovn-controller by sending samples to external IPFIX collectors. >>> >>> - Using the sample action, we don't need to rely on a meter to limit the >>> amount of data we process since we have the sampling >>> rate/probability. >>> >>> - Using IPFIX as standard format makes the solution interoperable so >>> it's possible to combine with other IPFIX sources to build >>> comprehensive observability tools. >>> >>> This RFC includes a prototype implementation based on the creation of a >>> new NBDB table "Sample" and a reference to it from the ACL table. This >>> would allow the use of per-flow IPFIX sampling to add visibility to >>> other areas of OVN as the needs arise. >>> >>> [1] >>> https://patchwork.ozlabs.org/project/ovn/patch/20221017131403.563877-2-amorenoz@redhat.com/ >>> >>> >>> Adrian Moreno (2): >>> northd: add ACL Sampling >>> ovn-nbctl: add sample to acl-add >> >> Hi Adrian, >> >> Do you plan to submit formal patches ? Or you're expecting any >> feedback on this series before submitting formally ? >> >> If so, I can take a look at the rfc patches. >> > > Hi Numan, > > I am planning to do some performance benchmarking and add it to the > formal patch but I would love to get some general feedback on the topic. > Whether the approach seems sane (adding sample actions in ACL lflows), > whether the general NBDB API is going in the proper direction or if > there is some pitfall I'm ignoring. Of course I'm not asking for a full > review but a general go/no-go would be nice. Hi Adrian, I'm not sure if Numan has other comments. FWIW I had a look at the two patches in the series and I think the direction is ok. I did share some comments on patch 1/2. Thanks for working on this! Regards, Dumitru
On 3/30/23 12:03, Dumitru Ceara wrote: > On 3/21/23 10:48, Adrian Moreno wrote: >> >> >> On 3/17/23 20:59, Numan Siddique wrote: >>> On Tue, Oct 18, 2022 at 12:00 PM Adrian Moreno <amorenoz@redhat.com> >>> wrote: >>>> >>>> Based on the introduction of the OVN "sample" action (still WIP) [1], >>>> the proposal of this RFC is to use per-flow IPFIX sampling to increase >>>> visibility on ACLs. >>>> >>>> The idea of ACL sampling is very similar to the already existing ACL >>>> logging whith the following key differences: >>>> >>>> - Using IPFIX sampling collects header information of the actual packet >>>> that was dropped / accepted by the ACL. This information is key to >>>> debug an issue or understand the traffic profile that traverses the >>>> ACLs. >>>> >>>> - With ACL logging, the information goes to the ovn-controller, >>>> adding pressure to it. Using IPFIX sampling can offload the >>>> ovn-controller by sending samples to external IPFIX collectors. >>>> >>>> - Using the sample action, we don't need to rely on a meter to limit the >>>> amount of data we process since we have the sampling >>>> rate/probability. >>>> >>>> - Using IPFIX as standard format makes the solution interoperable so >>>> it's possible to combine with other IPFIX sources to build >>>> comprehensive observability tools. >>>> >>>> This RFC includes a prototype implementation based on the creation of a >>>> new NBDB table "Sample" and a reference to it from the ACL table. This >>>> would allow the use of per-flow IPFIX sampling to add visibility to >>>> other areas of OVN as the needs arise. >>>> >>>> [1] >>>> https://patchwork.ozlabs.org/project/ovn/patch/20221017131403.563877-2-amorenoz@redhat.com/ >>>> >>>> >>>> Adrian Moreno (2): >>>> northd: add ACL Sampling >>>> ovn-nbctl: add sample to acl-add >>> >>> Hi Adrian, >>> >>> Do you plan to submit formal patches ? Or you're expecting any >>> feedback on this series before submitting formally ? >>> >>> If so, I can take a look at the rfc patches. >>> >> >> Hi Numan, >> >> I am planning to do some performance benchmarking and add it to the >> formal patch but I would love to get some general feedback on the topic. >> Whether the approach seems sane (adding sample actions in ACL lflows), >> whether the general NBDB API is going in the proper direction or if >> there is some pitfall I'm ignoring. Of course I'm not asking for a full >> review but a general go/no-go would be nice. > > Hi Adrian, > > I'm not sure if Numan has other comments. FWIW I had a look at the two > patches in the series and I think the direction is ok. I did share some > comments on patch 1/2. > > Thanks for working on this! > Thank you for your comments and feedback. > Regards, > Dumitru >