Hello Splunkers,
For an unknown reason, I'm not able to open a case so I'm describing the issue here today.
I'm using the sim_forwarder_assets in my company to monitor the possible loss of UF & HF, it's working well and is easy to maintain.
Today Splunk introduces an update (3.28.0) : https://docs.splunk.com/Documentation/SplunkCloud/9.2.2403/ReleaseNotes/CloudMonitoringConsole
And since this update (around 2PM UTC), I'm experiencing a lot of HF & UF marked as "missing" but in fact they are not and they are working perfectly well.
So I dig in the scheduled search responsible of the build & maintain of the sim_forwarder_assets and found the issue.
Schedule Search Name : SIM SS - Forwarder Build Asset Table
The following macro at the top is the following : `sim_build_forwarder_assets(1m)`
index=_internal sourcetype=splunkd TERM(group=tcpin_connections) TERM("cooked") OR TERM("cookedSSL") (hostname!=*.splunk*.*) fwdType!="edge"
| lookup reserved-cidrs cidr_block AS sourceIp OUTPUT cidr_source
| where isnull(cidr_source)
So Splunk is searching for hosts that are not in the lookup reserved-cidrs,
This lookups contains some of well-known multicast address and some reserved subnets over internet but it also contains some GCP IPs shared with customer :
| 34.0.0.0/15 |
gcp |
Public IP addresses for Google APIs and services including Google Cloud netblocks. |
However in my case and I believe in other customers too some on my HFs are presented on Splunk Cloud as with GCP Public IPs (34.X & 35.X)
As most of the GCP supernets are present in this lookup, my HF are declared as "missing" due to that.
I assume that Splunk should not include this kind of supernet in the lookup.
I do not know if everything is clear and I'm sorry for my poor english :).
