We have Splunk enterprise 6.2. We built splunk query that returns me all IP transacting with their country location and we are running it for last 60 minutes. Below is the query for same:
sourcetype="WebSphere:HTTPlog" |fields websphere_true_client_ip|dedup websphere_true_client_ip|table websphere_true_client_ip|iplocation websphere_true_client_ip|fields websphere_true_client_ip,Country|dedup websphere_true_client_ip,Country|table websphere_true_client_ip,Country
We noticed that some of the IP locations are not reported correctly. Below are example that shows up as US but are actually Australia.
IP Location Splunk Country Actual Country
184.108.40.206 United States AUS
220.127.116.11 United States AUS
18.104.22.168 United States AUS
22.214.171.124 United States AUS
It seems it does not have correct IP database OR IP database is not refreshed.
Old thread but no final solution explanation given so I wanted to share a solution as we were facing a similar issue:
We experienced the behaviour when using iplocation in conjunction with eventstats.
When iplocation was used before eventstats, the location was correct, when used after eventstats, it was wrong.
Eventstats (as well as stats) is a data processing / non-streaming command (-> it runs on the search head). Iplocation is a distributable streaming command (-> it can run on the indexer).
So using IP location BEFORE eventstats (and right after the base search) makes it run on the indexers.
When using iplocation AFTER eventstats it runs on the search head.
The reason for yielding different location results was due to different iplocation database versions (GeoLite2..) on search head and indexers.
So make sure, your geo location db is up-to-date and identical on all your Splunk components then iplocation yields the same results regardless where it is used in the search.
Where you place it depends on your search.
Usually it is advisable to enrich AFTER transforming/aggregations commands like stats or eventstats. But as iplocation is a distributable streaming command it might perform better when it can run on the indexers instead of the search head.
Generally speaking, the accuracy of the lookup is based on specific factors such as:
1. Structure your Splunk search query so that you 'dedup' BEFORE using 'iplocation'
2. Having an up-to-date MMDB file in Splunk
3. Whether or not the raw database (MaxMind's DataBase (mmdb), by default) is accurate based on its current content (even if you have the most current copy).
I have seen the same issue occur if you put dedup after iplocation. If your data and search structure permits, always ensure your
|dedup command preceeds
|iplocation in the search query. Too, you would then usually improve performance / reduce search-load by throwing less unique values for iplocation to process.
As ryanoconnor mentioned as well, keeping your maxmind db up-to-date is important. I typically download the new file the 1st Thursday of each month from maxmind.com. Maxmind usually begins updating their 'free' copy the 1st Tuesday of ea month. I often notice the new file is not ready until late Wednesday. Creating a simple scripted input in a new app, utilizing tools like wget/curl to regularly download the new file in your script and maybe set an interval by cron should help with maintenance here. Otherwise, I believe Splunk updates this file with each new maintenance release.
SPLUNK FILE LOCATION:
"$SPLUNK_HOME/share/GeoLite2-City.mmdb" (default location)
By default, Splunk includes the 'free' version of the mmdb file. You can even subscribe to Maxmind's precision service if super-high accuracy might be an operational requirement.
Where to get the latest mmdb: http://dev.maxmind.com/geoip/geoip2/geolite2/#Downloads
Sample download link: http://geolite.maxmind.com/download/geoip/database/GeoLite2-City.mmdb.gz
There are a few scripts out there available by now. I just deployed a custom script in my environment for ksh in Linux. Best of luck.
This likely has to do with the version of the IP Database that is being used. This database is updated with Maintenance releases of Splunk. I would recommend upgrading from 6.2 if you can.