+++ This bug was initially created as a clone of Bug #2032562 +++ Description of problem: We are using ML2/OVN which does not support the neutron l3-agent or meter-agent. We need metrics (statistics) on the Neutron router for traffic entering/exiting the cloud through the neutron router. We implement a neutron router per project and need to capture the traffic statistics. We cannot measure the traffic for a customer through the neutron router to/from the internet at the cloud. This prevents billing for this traffic. Version-Release number of selected component (if applicable): RHOSP 16.2 with STF enabled (STF 1.3) Running OpenShift 4.7 /STF 1.3 monitoring the cloud. --- Additional comment from Leif Madsen on 2021-12-14 20:36:21 UTC --- Moving this to OpenStack project as data collection needs to happen there first. Consumption of existing data into STF and doing something with it is a separate endeavour that is dependent on data collection existing first. --- Additional comment from Anita Tragler on 2022-01-21 18:46:41 UTC --- This is high priority and urgent feature request for Teclo Edge customers Lumen to get egress traffic metrics with DVR for each FIP (tenant) so that they can bill their cloud customer Tenants for egress external bandwidth Gbps consumed. This is must-have for LUmen to go into production. Current deployment is with OVS-DPDK but future deployment needs support with OVN HW offload as well. Lumen is our fist Telco Edge customer on OVN and we would like to make them successful. Currently OVS metrics and stats are supported for non router (non FIP) ports. If Lumen has a provider network for external traffic then metrics are available. When using DVR with FIP, this uses conntrack and multiple OVS tables which can change when new features are added, so it is not easy to get stats from routed FIP (SNAT/DNAT) flows. Need support from Core OVN team on how to get bandwidth metrics for SNAT/DNAT conntrack flows wiht Flaoting IPs. This is a new RFE that needs to be prioritized with core OVN team. Please create BZ for core OVN support and plan for OSP 16.2z --- Additional comment from RHEL Program Management on 2022-01-21 18:46:51 UTC --- This bugzilla has been removed from the release since it does not have an acked release flag. For details, see https://mojo.redhat.com/docs/DOC-1144661#jive_content_id_OSP_Release_Planning.' --- Additional comment from Red Hat Bugzilla on 2022-02-22 05:43:33 UTC --- remove performed by PnT Account Manager <pnt-expunge> --- Additional comment from on 2022-07-15 15:23:53 UTC --- Requested metrics Name Type Unit Resource Origin Note bandwidth Delta B label ID Notification Bytes through this l3 metering label network.outgoing.bytes.rate Gauge B/s interface ID Pollster Average rate of outgoing bytes network.outgoing.packets.rate Gauge packet/s interface ID Pollster Average rate of outgoing packets network.outgoing.packets.drop Cumulative packet interface ID Pollster Number of outgoing dropped packets network.outgoing.packets.error Cumulative packet interface ID Pollster Number of outgoing error packets --- Additional comment from on 2022-07-24 16:49:32 UTC --- === In Red Hat Customer Portal Case 03099034 === --- Comment by Anthony Link on 7/24/2022 12:49 PM --- [internal] @eng, any update ? --- Additional comment from Bernard Cafarelli on 2022-08-04 10:25:17 UTC --- Upstream, ML2/OVS with metering agent provides statistics at L3 level, for a given IP range. But this metering driver is not supported in OSP and will not work with OVN - it relies on qrouter namespace and iptables to track traffic. Customers have requested metrics for L3 objects, both routers and FIP. To account for all possible use cases, we should have generic bandwidth metrics per port (bytes in/out), exported from OVS -and centralized? (in OVN northbound database). This will also allow other OVN users like OCP to get access to these metrics. Router metrics can be gathered from the relevant router port (external network port), FIP from the port itself. STF will then collect these metrics (either at compute level or controller/central database) to expose relevant statistics. On the research side to confirm this RFE feasibility, it will need core OVN feedback (how to get these metrics, where to store, can they be centralized, ...), neutron needed parts (if any), checking with STF if proposed solution can be used there --- Additional comment from Bernard Cafarelli on 2022-08-04 13:18:22 UTC --- From squad meeting, security group logging implementation uses core OVN meters, it may be worth checking these: https://docs.openstack.org/neutron/latest/contributor/internals/ovn/ovn_network_logging.html
Hi Mark, Let's see if we can start converging on a clearer set of requirements. Let's start with the following list and let's iterate over it until it is fully clear: 1) Counters to collect: bytes and packets counters. 2) What entities to collect counters from: logical switch ports, routers, logical router ports, nats 3) How will the counters be delivered to the CMS. I see two alternatives. The first one is just to associate additional columns to the corresponding entities in the NBDB with byte and packet counters. In this alternative the association to time periods would be the responsibility of the CMS. A second alternative could be a new table in the NBDB where each row indicates the entity it refers to, the counters and the time period covered. I will be off on PTO February 15th - 28th, but Christophe Fontaine will be following up with you during my absence. What other details you need to move forward with this request? @mmichels
This issue is being closed as an automatic process due to the issue's age. If you wish to re-open this issue, please do so in Jira (https://issues.redhat.com) in the 'FDP' project. Please be sure to set the component to the latest OVN version where this issue is known to occur. If this is a feature request or improvement, please set the component to 'OVN'.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days