Architecture of ulogd2 1. Applications 1.1 ipfix exporter: - receives ctnetlink messages for 'delete' events - creates two ipfix flow records according to a fixed template - sends ipfix flow record over tcp, udp or sctp (ssl support!) - optional - maintain rules about which flows to export - support multiple outbound connections to multiple collectors 1.2 ipfix collector: - receives ipfix messages based on any kind of template - aggregates flow records in in-memory database - can export flow records based on plugins 2. generalization: - flow metering (input) plugins - flow based - ctnetlink / ctacct - flowcache? - ipfix packets - packet based - ulog - PF_PACKET - flow filtering plugins - aggregator (like net-acct) - real filter - grouping - flow exporting (output) - mysql - ipfix packets 3. random ideas: - stackable plugins - admin defines order of stack - any plugin looks the same to the core - no difference between input, output, filter - multiple stacks can be configured at the same time - attributes of stackable plugin - name - config keys - itype (null|packet|flow) - otype (packet|flow|null) - input function - gets data from underlying module - not existing (NULL) for real acquisitors - return value: chain of ulog_iret_t - signal handler - core exports functions to register filedescriptors for main select loop (for in/out fd's) - output plugins at very end of chain specify which field_id's they require as input. this template is then handed backwards up the chain[tree] to the input plugins - problems: - multiple interpreters can return same value (i.e. sport/dport) - some outputs/filters will require _ALL_ keys (e.g. OPRINT) Plugin stack building - start at final output plugin in stack. - pass list of input keys to previous plugin in stack - next plugin in stack verifies that it can provide those keys, and determines it's required input keys. pass them to next plugin if current plugin cannot support this key, a plugin further up the stack could! two-pass approach: 1) connect next<->prev pointers so plugin stack is known 2) start from output plugin and go upwards - list of "can provide" keys should be per instance, since configuration parameters could determine the possible keys. -LATER