Archive2

TCP logging incorrect

Explorer

I wanted to make use of TCP logging on my ASA/FSWM to ensure a higher reliability of logged events. In doing so, the cisco_firewall source type does not seem to index the data correctly. In most cases any lines which would indicate a connection teardown would create the hosts data type as "bytes". Also in all the other lines, there seems to be a random number to start off each line, such as <166> or <164>.

I'm new to using splunk, so I was wondering if this is a known issue. I have since put the logging to use UDP for these devices and it's working as expected at this point.

0 Karma
Reply
1 Solution

SplunkTrust
SplunkTrust

This is a partial answer at least.

The <166> and <164> stuff at the head of every log message is the Syslog facility/severity data. This comes through in from an ASA via UDP as well, but is filtered out by Splunk's UDP processor. You might be able to filter it out using SEDCMD.

For our environment, we wound up writing a C program to act as the PIX log catcher, writing to a flat file that Splunk reads. We filter the data there. We started out trying to use rsyslog, but there was something about the PIX/ASA TCP syslog data that it did not like.

Hopefully more to come on the "bytes" issue - I need to download/install Will's latest app.

View solution in original post

SplunkTrust
SplunkTrust

This is a partial answer at least.

The <166> and <164> stuff at the head of every log message is the Syslog facility/severity data. This comes through in from an ASA via UDP as well, but is filtered out by Splunk's UDP processor. You might be able to filter it out using SEDCMD.

For our environment, we wound up writing a C program to act as the PIX log catcher, writing to a flat file that Splunk reads. We filter the data there. We started out trying to use rsyslog, but there was something about the PIX/ASA TCP syslog data that it did not like.

Hopefully more to come on the "bytes" issue - I need to download/install Will's latest app.

View solution in original post

Explorer

I beefed up the system net rmem/wmem to 16MB and so far the UDP process hasn't dropped any packets. Our core FWSM does about 1 million indexes per hour, which seems to be a pretty hefty amount.

I just want to make sure that the system isn't losing any data if possible when using udp. This is a trial run for us to use splunk, currently I just output data to flat files on a syslog-ng server.

0 Karma
Reply

Splunk Employee
Splunk Employee

You could filter it out with SEDCMD or with LINE_BREAKER.

0 Karma
Reply