topic Re: How to query _TCP_ROUTING key value? in Splunk Search

How to query _TCP_ROUTING key value?

jcspigler2010 — Tue, 29 Sep 2020 14:56:53 GMT

Hello all

Is there a way you can query event's _TCP_ROUTING key value in a search? I would assume you should be able to since its being written in the events meta. We have bit of a complicated data routing and filtering issue and a search like this would be super helpful.

Thanks!

Re: How to query _TCP_ROUTING key value?

somesoni2 — Tue, 29 Sep 2020 14:59:00 GMT

I don't believe the _TCP_ROUTING is written into metadata for each event. It's an attribute used by Splunk engine (of heavy forwarder/indexer) to route events to different queue/ tcpout groups, it's not assigned to event.

Re: How to query _TCP_ROUTING key value?

s2_splunk — Wed, 19 Jul 2017 18:55:14 GMT

Correct, hence converted to answer for your convenience. 🙂

Re: How to query _TCP_ROUTING key value?

jcspigler2010 — Tue, 29 Sep 2020 14:57:20 GMT

Thanks somesoni2!

Sorry for the delay in credit. Was onsite with a customer all day. If you would be so kind to humor my next question. I can always start another thread if need be.

But we have an odd requirement at a client site where they index EVERYTHING sent from a heavy forwarder to an indexer and then send 2 or 3 source types off to a remote indexer. Now I know this isn't the conventional or best practice way of doing stuff, but due to political and environment boundaries, they have to forward data from the indexer and not the HF. HF would obviously be the optimal place to do this. So my question is, can we set the _TCP_ROUTING key at the HF level, and use it for routing and forwarding decisions at the indexer level? I guess the question generalized, does the DEST_KEY and FORMAT values persist from splunk instance to splunk instance or is just internal to that instance. I am going to test this out this week but figured someone would already have the answer.

Thanks!

Re: How to query _TCP_ROUTING key value?

somesoni2 — Wed, 19 Jul 2017 21:07:14 GMT

The routing transformation are applied during cooking/parsing of data, which will be done at Heavy forwarder level in your use case. Once cooked/parsed at HF level, it won't be parsed again (default and understandably) at indexer level. Now you can configure Indexers to re-parse the data but a) not recommended, b) it can't be done for a single sourcetype, but will be done for all data coming to indexers. So, basically you'll be doing double processing, consuming double resources and double latency for parsing. If that's something you can live with, see this on how to implement it.

https://answers.splunk.com/answers/97918/reparsing-cooked-data-coming-from-a-heavy-forwarder-possible.html
https://answers.splunk.com/answers/224312/hf1-hf2-indexer-how-to-route-a-set-of-data-that-ha.html

One more thing, you'll need to ensure that your Indexers have all the props.conf/transforms.conf that are in Heavy forwarder (because of re-parsing).

Re: How to query _TCP_ROUTING key value?

jcspigler2010 — Wed, 19 Jul 2017 21:22:53 GMT

Thanks somesoni2

Re: How to query _TCP_ROUTING key value?

s2_splunk — Thu, 20 Jul 2017 22:01:49 GMT

Hmmmm, while semantically correct, I don't think that's applicable. You should be able to affect TCP routing wherever you have an outputs.conf. Functionally, an indexer is nothing other than a heavy forwarder that writes to disk, so you should be able to that there as well.

Re: How to query _TCP_ROUTING key value?

anand_singh17 — Fri, 15 Sep 2017 11:36:31 GMT

But after lot trials, not able to forward data from indexers.

Re: How to query _TCP_ROUTING key value?

s2_splunk — Fri, 15 Sep 2017 21:25:41 GMT

Are you sure you followed the documentation on the topic and placed the appropriate configuration files in the appropriate places?

IndexAndForward should work just fine on an indexer...?

Re: How to query _TCP_ROUTING key value?

anand_singh17 — Sun, 17 Sep 2017 05:02:08 GMT

Hi Ssievert,

We do not have HF, where we can apply these configs.

We have 500 devices and have 98% of them sending data from UF, so as per optimization, we did not go for HF.

When applying the settings, UF is not able to process them.