Why is my search with the strcat command failing to retrieve results from Cisco ACL logs (vector::_M_range_check)?

[kwsk_t2y]

Hi all.

I'm trying Splunk Free (ver 6.3) and I am trying to search Cisco IOS ACL logs, but I don't get any results.

i) Search that does not work:

eventtype=cisco_ios-acl_log | strcat protocol "://" dest_port protoDestPort | chart sum(packets) over action BY protoDestPort

It is error. Result is "vector::_M_range_check".
but,
ii) Working search:

eventtype=cisco_ios-acl_log | chart sum(packets) over action BY dest_port

It is good.

It seems to fail on strcat command.

I have no idea. What should I do?

thanks.

[mikaelbje]

Bug SPL-107253 is fixed in Splunk 6.3.1 which is out now.

[kwsk_t2y]

Thank for your info!
I try now.

best regards

[mikaelbje · Accepted solution]

I filed this as a bug in the Splunk Beta program, but it seems that it may not have been fixed after all. I suggest you open up a case with Splunk providing them with diags from your setup.

What OS are you running?

http://answers.splunk.com/answers/313974/cisco-networks-app-for-splunk-enterprise-why-am-i.html seems to have a similar issue.

Update: I just now upgraded a Linux distributed environment from 6.2.4 to 6.3.0 using the latest Cisco Networks app and add-on. Seeing the same issue. Reverting to the following works:

eventtype=cisco_ios-acl_log | eval protoDestPort=protocol + "://" + dest_port  | chart sum(packets) over action BY protoDestPort

strcat should still be valid, so I guess this is a bug. Splunk Engineers?

Update 2: searches for raw events, i.e. sourcetype=cisco:ios do not work. This is because of the Vendor Message lookup which is a large CSV file. This worked in 6.2.4. It was reported as a bug in Splunk Beta, but was apparently not fixed before official release.

[kwsk_t2y]

Thanks a lot !
This search is good work!

[kwsk_t2y]

Thanks a lot!
I'll try this tonight and then report result.

NOT "strcat" BUT "eval"

[bochmann]

I'm getting vector::_M_range_check messages on our Splunk Enterprise 6.3 instance, too. The affected queries use another string function, though: convert ... ctime()

I have the impression that this primarily happens with long-running queries in dashboards, but I haven't had the time for any debugging up to now. The same queries were fine before the update (in 6.2.4).