-
Bug
-
Resolution: Done
-
Major
-
netobserv-1.10
-
Quality / Stability / Reliability
-
False
-
-
3
-
None
-
None
-
None
-
NetObserv - Sprint 280
-
None
-
None
-
Previously, some OVN specific IP addresses captured by netobserv were not enriched because not matching any known pods or nodes. Specific OVN subnets have been added to configuration so that they are now correctly recognized.
Description of problem:
Some IPs declared by OVN are not enriched and don't appear in Machines network as they should. E.g. 100.64.0.x can be seen when using the new Service deployment model, as the traffic source coming from our eBPF agents.
Steps to Reproduce:
1. Install netobserv with the new deploymentModel: Service (see https://github.com/netobserv/network-observability-operator/pull/1953) 2. Check traffic to DstNamespace=netobserv DstPort=2055 3.
Actual results:
Source of this traffic is an unenriched IP such as 100.64.0.x SrcSubnetLabel is empty
Expected results:
At least, SrcSubnetLabel should be Machines At best, the source should be recognized as being a Node
Additional info:
- Slack thread (internal): https://redhat-internal.slack.com/archives/C06HPKP6P5Z/p1762959158551069?thread_ts=1762955368.826229&cid=C06HPKP6P5Z
- This is v4InternalSubnet (default 100.64.0.0/16) or v6InternalSubnet (default fd98::/64) which can be overridden in CNO config https://github.com/openshift/cluster-network-operator/blob/master/manifests/0000_70_network_01_networks.crd.yaml#L621-L635
- Additionally, there is UserDefinedPrimaryNetworkJoinSubnetV4 = "100.65.0.0/16" / UserDefinedPrimaryNetworkJoinSubnetV6 = "fd99::/64"
- There are also IPs such as 172.20.0.1, which is the apiserver endpoint, as in `oc get endpointslices --all-namespaces | grep "172."`