summaryrefslogtreecommitdiffstats
path: root/ARCHITECTURE
blob: f825a0a8f7a4e5fdec10293fff95668a6edcbf7d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
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