I am trying to find a way to turn an IP address into CIDR format to group by reports. Ideally, I'd be able to do something like:
eval ip_sub=ciderize(ip,25)
So, for instance, an address of 172.20.66.54 in the forumla above would return 172.20.66.0/25, while 172.30.66.195 would return a value of 172.20.66.128/25.
I know I could do it with a lookup table if the number of ranges were known/small, but I'm trying to have some level of grouping for external IP addresses in our firewall logs. Maybe I'm just missing something obvious?
Your approach of using a lookup is good, but I'd suggest a scripted lookup rather than a static CSV lookup (alternately you could use a custom search command; a discussion of the differences are at http://splunk-base.splunk.com/answers/3890/pros-and-cons-external-lookup-script-vs-custom-search-com...).
If you were to use a lookup, the contract the script would advertise is simple, it is presented three columns corresponding to IP address, one for the number of bits and one for the CIDR address, typically with the CIDR address left blank. Its task would be to fill out that column. For simplicity, you might want to make one lookup function and 32 lookup tables in transforms.conf, each which sends the number of bits to the script, so that you only have to provide two columns.
A search command could do the same thing.
just for clarity, the question is not 100% accurate from a mask syntax perspective. a IP in a subnet, in CIDR syntax, comes out as IP/mask, not Network/mask. the problem is how to return the Network (aka subnet) in CIDR syntax for any given IP.
Your approach of using a lookup is good, but I'd suggest a scripted lookup rather than a static CSV lookup (alternately you could use a custom search command; a discussion of the differences are at http://splunk-base.splunk.com/answers/3890/pros-and-cons-external-lookup-script-vs-custom-search-com...).
If you were to use a lookup, the contract the script would advertise is simple, it is presented three columns corresponding to IP address, one for the number of bits and one for the CIDR address, typically with the CIDR address left blank. Its task would be to fill out that column. For simplicity, you might want to make one lookup function and 32 lookup tables in transforms.conf, each which sends the number of bits to the script, so that you only have to provide two columns.
A search command could do the same thing.
accepting this lacking more elegant (ie, built-in) solution... may look at integrating with whois lookup- was looking at a couple of the apps on splunkbase.