Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Openvswitch ovs-vsctl connection #99

Open
ekfoury opened this issue May 25, 2021 · 8 comments
Open

Openvswitch ovs-vsctl connection #99

ekfoury opened this issue May 25, 2021 · 8 comments

Comments

@ekfoury
Copy link

ekfoury commented May 25, 2021

Hello everyone,

I would like to ask if anyone was able to use the openvswitch IPFIX with goflow.
I tried openvswitch/goflow with sFlow and NetFlow, and both work great. With IPFIX, nothing is shown on the collector.

Has anyone experienced the same issue?

Thanks.

@lspgn
Copy link
Contributor

lspgn commented May 25, 2021

Hello,
Do you have a packet capture?
There might be an issue if it's using Enterprise format (listed in #31).

@ekfoury
Copy link
Author

ekfoury commented May 25, 2021

Hello lspgn,

Attached is a pcap sample. I can see the IPFIX flows in wireshark, but nothing is appearing in goflow.

Thanks for your help.

ipfix.tar.gz

@lspgn
Copy link
Contributor

lspgn commented May 25, 2021

Could you give me the CLI arguments you are passing?

@ekfoury
Copy link
Author

ekfoury commented May 25, 2021

I am starting goflow like this:
sudo docker run --net=host -ti cloudflare/goflow:latest -kafka=false

And configuring the exporter on ovs like this:
sudo ovs-vsctl -- set Bridge s1 ipfix=@if -- --id=@if create IPFIX targets="127.0.0.1:2055" sampling=64

@lspgn
Copy link
Contributor

lspgn commented May 25, 2021

After looking at the pcap, I noticed there are custom Enterprise fields in the templates. Unfortunately, this is issue #31 and the templates aren't properly decoded.
If you can change the template that OVS is sending or change to NetFlow v9, it should collect without issues.

I am currently working on a fix and hope to have something in the coming days (after some freeze).

@ekfoury
Copy link
Author

ekfoury commented May 25, 2021

Gotcha! thanks for the help. I will just use NetFlow v9 for now. I will keep an eye on issue #31 for the future.
Thanks.

@jotak
Copy link

jotak commented Aug 5, 2021

FWIW here's a descriptive XML from ovs: https://github.com/openvswitch/ovs/blob/master/ofproto/ipfix.xml
I'm trying to understand, for this issue with ovs to be fixed (ie. Enterprise format not being supported with goflow and breaking the decoder), am I right to assume that the work could be split in two parts:

  1. implement reading the enterprise number as per https://datatracker.ietf.org/doc/html/rfc7011#section-3.2
  2. interpret these fields using some descriptor such as the link I wrote above

1. can be done and would fix goflow when receiving the common IPFIX fields, though ignoring the custom ones. Am I understanding correctly?

@jotak
Copy link

jotak commented Aug 5, 2021

I could make it work "partially" with ovs, standard fields are now recognized and collected ; there's not only the enterprise number parsing missing, but also variable length fields [1] such as string that are not supported currently in goflow. I can submit a fix after cleaning my work.

[1] cf https://datatracker.ietf.org/doc/html/rfc7011#section-7

ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Oct 19, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow_v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv4 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)
ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Oct 19, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow_v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv4 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)

Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Oct 19, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv6 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)

Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Oct 26, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv6 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)

Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Oct 26, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv6 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)

Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Oct 27, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv6 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)

Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Oct 27, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv6 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)

Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Oct 27, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv6 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)

Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Oct 28, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv6 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)

Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Oct 29, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv6 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)

Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
ricky-rav added a commit to ricky-rav/ovn-kubernetes that referenced this issue Nov 23, 2021
…int in existing netflow test

- Existing netflow export test now supports netflow v5, ipfix, sflow.
- The original test only validated the export of netflow v5 (legacy netflow) data, which does not support IPv6 by design. In order to validate flow data export in an IPv6 cluster, we can now choose between IPFIX and sflow; also, the test now supports an IPv6 endpoint;
- For the time being we're only testing netflow v5 in IPv4 (as before) and sflow in IPv6, because:
  (1) The test itself is long (~5 minutes);
  (2) The current implementation of the flow collector container (cloudfare/goflow) doesn't support IPFIX data generated by OVS (cloudflare/goflow#99)

Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants