This searches for the relevant srcIPs that are showing up in the firepower index and returns a unique list, labeled as ip index=firepower AccessControlRuleName="Block Bittorrent" | dedup srcIP | table srcIP | rename srcIP as ip That output is just a table of ip values, which you can run into this command ... | format ...which turns it into this format... ( ( ip="firstip" ) OR ( ip="secondip" ) OR....) ...or, you can achieve the exact same thing by putting it with the word "search" inside of square braces, so the following line is the equivalent of the last line... [search index=firepower AccessControlRuleName="Block Bittorrent" | dedup srcIP | table srcIP | rename srcIP as ip ] ...so we can use that, the results of the first search, as a filter on the second search without getting within a mile of the word join . index=DHCP [index=firepower AccessControlRuleName="Block Bittorrent" | dedup srcIP | table srcIP | rename srcIP as ip] | dedup ip The last line limits the results to only the first, most recent results for each ip. Now, this formulation is assuming that the DHCP information is what you are primarily seeking, and that the DHCP information is large in relationship to the firepower information. If you needed to add back the firepower data under those circumstances, you could add something like this at the end... | join ip [ search index=firepower AccessControlRuleName="Block Bittorrent" | dedup srcIP| rename srcIP as ip] Now, if your bittorrent data is significant in relationship to your DHCP data -- one would hope not, but it needs to be considered based on your own use case -- then eliminating the initial filter and just using the join might be appropriate. Test them for performance and see. ... View more