Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for a new filter for netscout switches #2630

Open
aalisher-tmx opened this issue Oct 29, 2024 · 11 comments
Open

Request for a new filter for netscout switches #2630

aalisher-tmx opened this issue Oct 29, 2024 · 11 comments
Assignees
Labels
enhancement New feature or request

Comments

@aalisher-tmx
Copy link

Note: If your issue is not a bug or a feature request, please raise a support ticket through our support portal (Splunk.com > Support > Support Portal). This will help us resolve your issue more efficiently and provide you with better assistance. For more information on how to work with the Splunk Support, please refer to this guide.

What is the sc4s version?
v3.32
Is there a pcap available? If so, would you prefer to attach it to this issue or send it to Splunk support?
Splunk support case # 3604943 opened and attached pcap and raw events
What the vendor name?
Netscout
What's the product name?
nGenius 5000 Series Packet Flow Switches
If you're requesting support for a new vendor, do you have any preferences regarding the default index and sourcetype for their events?

Do you have syslog documentation or a manual for that device??

Feature Request description:

Do you want to have it for local usage or prepare a github PR?

@cwadhwani-splunk cwadhwani-splunk self-assigned this Oct 30, 2024
@cwadhwani-splunk cwadhwani-splunk added the enhancement New feature or request label Oct 30, 2024
@cwadhwani-splunk
Copy link
Collaborator

Hi @aalisher-tmx ,

After reviewing the pcap logs, we identified that the "program" field is consistent across all logs. Based on this, we’ve created a parser that filters logs with the program prefix value "TTQNM" and assigns the following metadata: source as netscout:switches, sourcetype as netscout:switches:syslog, and index as netops.
Please adjust any of these values if required.

To add the parser to your local environment:

  • Navigate to: /opt/sc4s/local/config/app_parsers
  • Create a new file named: app-syslog-netscout_switches.conf
  • Save the file and restart SC4S service.
block parser app-syslog-netscout_switches() {
    channel {
        rewrite {
            r_set_splunk_dest_default(
                index('netops')
                source('netscout:switches')
                sourcetype('netscout:switches:syslog')
                vendor('netscout')
                product('switches')
            );
        };
    };
};

application app-syslog-netscout_switches[sc4s-syslog-pgm] {
    filter {
        program('TTQNM' type(string) flags(prefix))
    };
    parser { app-syslog-netscout_switches(); };
};

Note: we have used prefix to check the program, with the logs that you have sent the program value is TTQNM-5010MS1, so if you wanna change the filter such that it classifies logs with program = TTQNM-5010MS1, you can change the filter with the below lines:
filter {
program('TTQNM-5010MS1' type(string))
};

@aalisher-tmx
Copy link
Author

Thanks for your prompt response @cwadhwani-splunk. I did setup the filter but they are going to main index now, defaulting to ".app.app-fallbackz-lastchance|.source.s_DEFAULT" sc4s_tags. i have uploaded the latest pcap file for your testing to the splunk case

@aalisher-tmx
Copy link
Author

will it make any difference to the filter as the pcap i have provided before was using protocol udp and the latest one attached to the case is tcp

@cwadhwani-splunk
Copy link
Collaborator

Hi @aalisher-tmx

We checked both the pcaps and found that the logs available in the previous PCAP were not framed, however the latest pcap file logs are in RFC5424 format with frames, meaning they start with the length of the syslog (e.g., 111 <14>...), which aligns with IETF TCP log format. This difference was causing the issue and because of this the parser that we provided was not getting applied.

So if you want to send the data via UDP (like the first pcap logs), you can use port 514, but for the IETF format, we recommend sending logs using port 601 over TCP (like the second pcap logs), as it supports the IETF format.

@aalisher-tmx
Copy link
Author

Thank you for the clarification @cwadhwani-splunk. WIll test it out and let you know.

@aalisher-tmx
Copy link
Author

@cwadhwani-splunk looks like i need to add a variable on the sc4s server to listen on port 601 to get this working, right? how to define this variable?

@cwadhwani-splunk
Copy link
Collaborator

SC4S by default listens on tcp/601 port, you dont need any variable to define it.

@aalisher-tmx
Copy link
Author

@cwadhwani-splunk by default udp/601 is listening on sc4s. I don't see tcp/601. Can you please reconfirm again. And also, are you able to ingest via tcp/601 in your test env.

@cwadhwani-splunk
Copy link
Collaborator

Hi @aalisher-tmx

Yep I have tried it in my environment and it works fine. Here is what you can try:
Check whether tcp/601 is in listening mode or not using the below command:

sudo netstat -tulnp | grep :601

If you dont see tcp/601 in listening mode, you can add the SC4S_LISTEN_DEFAULT_TCP_PORT in your /opt/sc4s/env_file, here is the reference link.
You can try setting it upto 601 or any other tcp port and then send your IEFT framed syslog to it.

@aalisher-tmx
Copy link
Author

Hi @cwadhwani-splunk By default, tcp/601 is not in listening mode. When I added SC4S_LISTEN_DEFAULT_TCP_PORT in /opt/sc4s/env_file file, all endpoints ingesting syslog with tcp/514 stopped ingesting. Looks like we are overwriting the default tcp port. Any suggestions?

@aalisher-tmx
Copy link
Author

@cwadhwani-splunk i posted comments on the splunk support case# 3604943. let me know

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants