That’s an excellent point. Actually you must do it or at least check if this is needed every time when you add a new data source. It not matter is it a new source system for indexing to current indexers or a totally new indexer or cluster to your SH. ... View more

Yes...this is my 1st deployment of this node.  I installed the software on a linux VM and at a minimum I would think it would be listening and waiting for data via port 9997.  It's definitely connecting to the cloud on that port.  I don't see anything in the edge.log file that would indicate why it's not listening on that port.  I do see the following but not sure what it may be referring to: "message":"current settings have previously caused failures. aborting update","type":"provided","status":"failed"},{"time":"2024-10-21T16:16:37.959Z","settings_id":"3080980952365928851","type":"telemetry","status":"running"}]}} ... View more

Hi @FPERVIL , I usually deploy on all the Forwarders an app, usually called TA_Forwarders, containing at least three files: app.conf deploymentclient.conf, outputs.conf. in this way I can centrally manage both sending data to Indexers and Conncection to Deployment Server. Ciao. Giuseppe ... View more

We have had this same issue in our environment.  The fix we have come up with is to create an app for the 4300X events that are specific to cisco:ftd where we parse out all the fields (you can use kvmode=auto for these, but some fields like url don't get extracted correctly since they oftentimes have '=' in the url string).   In order to address the other message IDs that match number/format with cisco:asa, we make a 'custom' app and update it each time we update Splunk_TA_cisco-asa.  In that app (we named it Splunk_TA_cisco-asa-ftd) we just copy over the /default/ and /local/ props.conf files and change the sourcetype declaration from [cisco:asa] to [cisco:ftd].  The other files (like transforms) aren't needed because splunk already has those definitions in the Splunk_TA_cisco-asa app, you just need to tell it to do all the eval/extract/transform/etc functions from props.conf for the other sourcetype.  If you use eventtypes, you should also update that. We updated Splunk_TA_cisco-asa/local/eventtypes.conf to use 'sourcetype IN (cisco:asa, cisco:ftd)' to address that issue in the 'standard' app. I know that seems like a lot of customization, but after doing the customization / upgrade a few times, it's not so bad.  🙂  ... View more

https://docs.splunk.com/Documentation/VersionCompatibility/current/Matrix/Compatibilitybetweenforwardersandindexers Generally. Unless you're using httpout, you're good whatever combination of versions from not-so-ancient releases you choose (actually I ran forwarders as farback as 6.6 with 9.0 indexers but that's not officially supported). The only annoyance is with 9.x UF and pre-9.0 indexers because 9.x UFs generate internal events for an indexer non-existent on pre-9.0 indexers so you end up with either warnings in splunk logs or events in your last-resort index. ... View more

You should remember that if any of those target stop to work this leads quite soon that also another targets will stop as soon as queues of stalled target will be full. ... View more

Many others have had the same problem after upgrading.  It seems the alert is too sensitive.  Once you have confirmed the instances are healthy, consider adjusting the alert threshold or disabling it. ... View more

I wouldn't have done it that way but this is probably setup as active/standby for UF.  Send data to 2 servers, and have them monitor one another.  If the standby detects that the active is gone, assume active status and start forwarding.  When the was-active comes back and sees the other server is active, assume standby status. ... View more