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
|
