CiscoNET

Splunk was configured as a Syslog server on my lab network for few weeks now. Since I modified few parameters on service side and configured network devices, firewall, switches and router, which sent syslog message to the Splunk server. Past few days it built pretty thick index database. Well my index size is way below than 500Mbyte daily limitation for free version of Splunk. I am not expecting huge errors and critical messages because it is small Lab and also I am only monitoring network devices.

Today, while I was playing and reviewing Splunk, I found some of device within network sending spoofing traffic which is sending packet to unknown network, 192.168.100.15(RFC1918). As far as I know I didn't set it up within the lab network.

Let's find out what's going on.

I have been testing Splunk window version on my Microsoft Window XP(32bits). Window version was easy to install and control Splunk software. But somehow, I don't feel like power of Splunk is fully used. Beside it kinds of slow than I thought. When I researched about Splunk, realized most of  power users are using either Linux or Mac OS version of Splunk. I decided install Splunk on OpenSuSE 11.  As usual I googled some install info before start installation and I found some interesting comments that "Do not use OpenSuSE for Splunk, it doesn't work". Yes, it happened to me. But there were tips to resolve the issue. See below notes.

Whole process of installation was fairly easy.  In this example, I will try to install Splunk with rmp version.

Using default TCP receive window size, 64 Kbytes (MS windows OSs, XP, Vista, 2003 server etc), not always is good if you have a high speed connections such as OCs and Gigabit Ethernet or extremely slow (?) connections such as Satellite link, 56 Kbps fractal T1s and so on. Because of TCP receive window size is not adequate for those network circumstance. TCP window scaling option (RFC 1323) will dramatically improve your TCP throughput, denoted download and upload speed. However, circuit condition should be under strict conditions as error free, no packet lost and no bottleneck. If a link condition is bad, TCP window scaling option makes worse TCP throughput. Let's dig more info why the window size is matter and how we can tune it to get faster download/upload speed (TCP throughput)

• Internet Speed Issue - Bandwidth VS. Throughput
• Internet Speed Issue - How to troubleshoot(FTP)
• Internet Speed Issue - How to troubleshoot(IPERF)
• Internet Speed Issue - Why TCP window size is matter
  
• Internet Speed Issue - How to use TCP window scaling option
• Internet Speed Issue - Optimal MTU size on VPN or others

From few simplifying test results on previous article "Internet Speed Issue - Why TCP window size is matter", indeed TCP window size made difference of TCP throughput and download & upload performance. Again, I don't think everybody move forward to TCP window scaling option. If you don't have high speed connections or unstable such as home users, don't need this option. It might bring worse TCP throughput than before. However, certain circumstance, this option is very useful. For example, data replicating from location A and B that has dedicated Gigabit links all the way device to device. Tuned proper TCP window size will increase huge TCP throughput. Of course link condition should be well maintained by network administrator. Let's how we can tune TCP window size on your device.

• Internet Speed Issue - Bandwidth VS. Throughput
• Internet Speed Issue - How to troubleshoot(FTP)
• Internet Speed Issue - How to troubleshoot(IPERF)
  
• Internet Speed Issue - Why TCP window size is matter
• Internet Speed Issue - How to use TCP window scaling option
• Internet Speed Issue - Optimal MTU size on VPN or others