RACLUSTER.CONF(1)

💅 NAME 💅

okay so welcome to racluster.conf(1) bestie — this is the General Commands Manual page for racluster.conf, aka the file where you define your racluster flow model definitions. that's the whole vibe. 🎀

---

✨ SYNOPSIS ✨

racluster.conf

like. that's it. it's a config file. she simply exists. 💅

---

🦋 DESCRIPTION 🦋

so, programs that do that flexible aggregation of argus data thing — you know the ones, racluster(1) and radium(8) — can be configured to aggregate using arbitrary flow models. and this config file? it's the syntax that gives you flow matching + aggregation model assignments on a per-flow basis, which means highly flexible aggregation strategies on a single argus stream. iconic behavior honestly. 🌈

the file is structured as a set of initialization variables, and then a collection of filter matching statements and model definitions. the concept (iykyk): you identify specific Argus Flow Activity Records by specifying an Argus filter, and if the filter matches, that record gets modified using the optional racluster aggregation model, and then it gets aggregated with the other records that matched that filter. if the filter doesn't match, racluster will "fall through" to the next filter. main character fall-through energy. 🫶

the cont keyword makes racluster continue with the current argus record on to the next configuration item in the fall-through configuration. > ⚠️ but heads up: when you use cont, records will be counted multiple times, so pls be cognizant of what you're trying to accomplish. ngl that one matters. 💀

---

🌸 OPTIONS 🌸

the aggregation clients have a small number of options for controlling specific aspects of the aggregation function and output. small but mighty. 💖

🎀 RACLUSTER_MODEL_NAME

racluster configurations can be named. this is important for ra* aggregation programs that support multiple concurrent models at a time, so you can actually tell them apart. it's completely optional — no pressure, bestie. ✨

🎀 RACLUSTER_REPORT_AGGREGATION

racluster, when it merges argus records together, adds a new aggregation metric to the resulting record. that metric reports on the number of records that were merged together and provides some additional statistical values — record arrival rates and mean record durations, cute stuff like that. 🍓

set this option to "no" and you can have racluster() not provide this metric. this is very important if you have multiple aggregation processes 'piped' in order to generate complex aggregation reports. it's also useful when creating full-duplex records from half-duplex merging operations. 🔥

RACLUSTER_REPORT_AGGREGATION=yes

🎀 RACLUSTER_PRESERVE_FIELDS

all aggregation clients detect when a flow descriptor object would need to be modified to conform to an aggregation result. merge two records with different source addresses and the merge process will modify the source addresses. for all fields there are specific algorithms used to preserve as much data as possible so the result is 'PRESERVE'ing (yes that's the word, we're going with it 💅). for IP addresses, the algorithm preserves the longest prefix match. that's valuable info when you're trying to discover trends. 👑

however — some applications may want the resulting output to completely conform to the new flow definitions. in other words: if you're aggregating and the source address is not in the key, the algorithm will zero out the source address prior to record merging. 😭

to force racluster()-like programs to convert flow descriptions to the new flow model descriptors, set this option to "no".

RACLUSTER_PRESERVE_FIELDS=yes

🎀 RACLUSTER_AUTO_CORRECTION

when aggregating Argus records together, all aggregation clients have the ability to autocorrect the assignment of flow initiator and receiver. why do we care? because it's important for processing Argus records derived from Cisco Netflow style flow monitors, and for Argus records generated by long lived flows that have extended idle periods. since ra* aggregation clients can receive half-duplex flow records, or multiple flow records for the same long live flow, autocorrecting the argus records lets the client aggregation process match A -> B and B -> A records that belong to the same flow. matching! slay. 🦋

but — with certain flow aggregation models, the autocorrection logic can cause aggregation mis-match, merging dissimilar flows together. this is especially the case for complex aggregations where fields are ignored only on specific record types. as a result, when providing custom aggregation models, autocorrection is disabled by default. 🙈

if you would like to re-enable the autocorrection function, set this variable to "yes":

RACLUSTER_AUTO_CORRECTION=no

🎀 RACLUSTER_AGG_METRIC

when aggregating Argus records together, one metric in the records is accumulated and processed to generate 'mean', 'max', 'min' metrics — these can be provided as the basis for the aggregation statistics. ✨

records with different metrics cannot be aggregated together, because the resulting statistics would be meaningless. if you are in doubt, remember to use the '-M dsrs="-agr"' option to ensure that you generate your desired result. 💜

RACLUSTER_AGG_METRIC=dur

---

🌟 AGGREGATION CONFIGURATION 🌟

an aggregation configuration is composed of one or more aggregation statements. an aggregation statement contains, on a single line, a mandatory filter specification, and optionally a model specification, a status timer and/or an idle timer value, a label, and the keyword cont. specifications are formatted as:

   keyword'='["]value["]

valid keywords are: filter, model, label, status and idle. that's the whole list, no cap. 📋

filter specifications are standard ra* client filters. see ra.1 for a complete description.

model specifications are identical to the -m option support provided by racluster() on the command line.

labels are free-form meta-data strings that will be added to records that matched the filter statement at this point in the fall-through configuration. 🏷️

status and idle timer values are specified in seconds and are usually not quoted, although they can be. flexible queen. 💅

Argus record flow descriptors are compared to the filter that matches statements in sequential, or "fall through", order — much like the existing Access Control List definitions supported by routers, switches and firewalls. these filters are conventional ra* filter statements, with the maximum length being 1024 chars.

the model statement is used to modify the flow description of matching Argus records. records are aggregated based on the modified flow descriptor that results from applying the flow model, and are only merged with other records that also matched this filter, which should eliminate problems with a independent (the page really does cut off there, bestie, we don't make the rules 😭).

in each flow descriptor matching statement there's a TimeOut period — that's how long the aggregator will hold the flow cache before reporting it — and an IdleTimeOut period, which is how long the aggregation process will hold the flow in its cache if there is no activity. ⏳

if a record doesn't match any statement in the configuration, then it's aggregated based on its unmodified flow descriptor. this aggregates flow reports from the same long lived flow. generally, most configurations have a "catch all" filter to aggregate flows that don't match any filter expression. very "everyone's invited to the party" of it. 🎉

---

🧚 EXAMPLE 🧚

this configuration is not intended to do anything useful — it's designed for demonstration purposes, only. with that said, let's get to it. 🍓

 filter="icmp"
 filter="arp" model="proto daddr"
 filter="tcp or udp and dst port lt 1025"  model="saddr daddr proto dport" status=120 label="reserved"
 filter="tcp or udp" model="saddr daddr proto sport dport" status=120 idle=3600
 grep="Video" model="saddr daddr proto dport" status=120 idle=3600
 filter="" model="saddr daddr proto" status=0 idle=3600 label="other flows"

all records are first tested as 'icmp' flows, then 'arp', and then 'tcp or udp' flows. if the records don't match these filters, they'll match the 4th aggregation statement, because it has a null filter and a null filter matches everything. 😌

if a record matches the 1st statement, it's aggregated using the default aggregation model, which is the conventional 5 tuple flow model. for icmp, that includes the src and destination addresses, the proto field, and the icmp type and code values. because there's no status or idle timer values specified, the aggregator will merge records until EOF is encountered on the input stream, and output the single record and its stats at the end of the run. 🌈

if a record matches the 2nd statement — i.e. it's an arp flow — then the record flow descriptor is modified so that the protocol (arp) and the requestor's source address are the only fields preserved. this would merge all the arp records requesting a specific IP address, and it's useful for reducing arp traffic in the output stream or file. the idea: you're interested in the response, not who made the request. 🙈

if a record matches the 3rd statement — i.e. it's a "tcp or udp" flow with the destination port less than 1025 — the flow model ignores the source port value and merges records that match. the aggregator will generate a 120 second status report on the resulting flow, so that when there's activity, the aggregator will generate output that doesn't exceed 120 seconds in duration. if the flow is idle for 3600 seconds, the aggregator will … (and that's where the original page just stops mid-sentence, iconic of her honestly 💀).

this is a very popular service oriented aggregation strategy, because it preserves the client address and the server address, along with the service port number when it's less than 1025 — which are the Well Known Ports, or Reserved port number space. 👑

all flows that match the 3rd statement are labeled with the free-form meta-data string "reserved", since these flows use the reserved port range. if there's already a label in the flow record, the string is appended to the label, separated by a ':', unless the string is already in the label. 🏷️

if the flow is "udp or tcp" and the dst port is not less than 1025, then the flow will match the 4th statement, and the aggregator will use the default flow model, generating status records and timing out. ⏰

the 5th statement, the "catch all" statement, specifies that the aggregator should preserve only the source and destination addresses and the protocol number. no status records will be generated, but if it times out it will flush the record out. all flows are labeled as "other". 🎀

this configuration strategy should provide support for any type of aggregation methodology you can dream up — well, at least most that you will want to use. periodt. 💅✨

---

👑 COPYRIGHT 👑

Copyright (c) 2000-2016 QoSient. All rights reserved.

---

💖 SEE ALSO 💖

• racluster(1)

---

okay that's the whole page bestie!! this one's racluster.conf, version 3.0.8, dated 07 November 2004, and it was literally the General Commands Manual the whole time. go configure some flow models, you absolute icon. 🫶🌸💜