blob: 20976b04777dd2ab1e98e3406ca3f321000a7115 (
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
|
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)
|