forked from pmacct/pmacct
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathpretag.map.example
174 lines (170 loc) · 8.08 KB
/
pretag.map.example
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
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
!
! Pre-Tagging map -- multiplexes various fields into a 4-bytes numerical-only ID
!
! File syntax is key-based. Position of keys inside the same row (rule) is not relevant;
! Spaces are not allowed (ie. 'id = 1' is not valid). The first full match wins (like in
! firewall rules). Negative values mean negations (ie. match data NOT entering interface
! 2: 'in=-2'); 'id', 'id2', 'ip' and 'filter' keys don't support negative values. 'label',
! 'jeq', 'return' and 'stack' keys can be used to alter the standard rule evaluation flow.
!
! nfacctd: valid keys: id, id2, ip, in, out, engine_type, engine_id, nexthop, bgp_nexthop,
! src_as, dst_as, peer_src_as, peer_dst_as, v8agg and filter; mandatory keys for each
! rule: id or id2 and ip.
!
! sfacctd: valid keys: id, id2, ip, in, out, agent_id, nexthop, bgp_nexthop, src_as,
! dst_as, sampling_rate and filter; mandatory keys for each rule: id or id2 and ip.
!
! pmacctd: valid keys: id, id2, src_as, dst_as and filter. Only either id or id2 are
! mandatory for each rule.
!
! list of currently supported keys follow:
!
! 'id' tag assigned to a matching packet, flow or sample; its use is
! mutually exclusive with id2. The resulting label is written to
! the 'tag' field when using memory tables and 'agent_id' when
! using a SQL plugin.
! 'id2' tag assigned to a matching packet, flow or sample; its use is
! mutually exclusive with id. The resulting label is written to
! the 'tag2' field when using memory tables and 'agent_id2' when
! using a SQL plugin. If using a SQL plugin, read more about the
! 'agent_id2' field in the 'sql/README.agent_id2' document.
! 'ip' IP address of the device which is originating sFlow or NetFlow
! datagrams (router, probe, etc.)
! 'in' Input interface
! 'out' Output interface
! 'engine_type' In NetFlow V5 it's compared against the 'engine_type' header
! field. In NetFlow V9 it's compared against the 3rd byte of
! the 'source_id' header field. Provides uniqueness with respect
! to the routing engine on the exporting device.
! 'engine_id' In NetFlow V5 it's compared against the 'engine_id' header
! field. In NetFlow V9 it's compared against the 4th byte of
! the 'source_id' header field. It provides uniqueness with
! respect to the particular line card or VIP on the exporting
! device.
! 'nexthop' IPv4/IPv6 address of the next-hop router
! 'bgp_nexthop' IPv4/IPv6 address of the next-hop BGP router
! 'filter' Matches incoming packets against the supplied filter expression
! (expected in libpcap syntax); the filter needs to be enclosed in
! quotes ('). In order to get support for MPLS label hierarchies,
! the use of CVS versions >= 06-06-2005 of libpcap is adviceable:
! they include the support for expressions like "mpls 100000 and
! mpls 1024" that will match packets/flows with an outer label of
! 100000 and an inner label of 1024.
! 'v8agg' In NetFlow V8 it's compared against the aggregation method in use.
! Valid values are in the range 0 > value > 15.
! 'agent_id' In sFlow v5 it's compared against the subAgentId field. sFlow v2
! and v4 lack of such field, so it does not apply.
! 'sampling_rate' In sFlow v2/v4/v5 it is compared against the sampling_rate field;
! It also works against NetFlow v5. NetFlow v9 is unsupported.
! 'src_as' source Autonomous System Number. In pmacctd it works only against
! a Networks map (see 'networks_file' directive); in nf|sfacctd it
! works against a Networks Map, the source ASN field in either sFlow
! or NetFlow datagrams and, since release 0.12.0, the BGP RIB of the
! exporting device (see 'nfacctd_bgp' directive).
! 'dst_as' destination Autonomous System Number. Same 'src_as' remarks hold
! here. Please read them above.
! 'peer_src_as' peering source Autonomous System Number. This is compared against
! the BGP RIB of the exporting device (see 'nfacctd_bgp' directive).
! 'peer_dst_as' peering destination Autonomous System Number. Same 'peer_src_as'
! remarks hold here. Please read them above.
! 'local_pref' Destination IP prefix BGP local preference attribute. This is
! compared against the BGP RIB of the exporting device.
! 'label' Mark the rule with label's value. Labels don't need to be unique:
! when jumping, the first matching label wins. Label value "next"
! is reserved for internal use and hence not to be used in a map.
! Using it might give unexpected results.
! 'jeq' Jump on EQual. Jumps to the supplied label in case of rule match.
! Jumps are Only forward. Label "next" is reserved and causes to go
! to the next rule, if any.
! Before continuing the map workflow, tagged data can be optionally
! returned to active plugins (ie. jeq=xxx return=true). Disabled by
! default (ie. return=false). Beware setting return=true, depending
! on configuration, can generate spurious data and/or duplicates;
! the logics by which this would work is: plugins which include 'tag'
! as aggregation will receive each tagged copy (if not filtered out
! by the pre_tag_filter directive, indeed); plugins not configured
! for tags will only receive a single copy of the data.
! 'return' Works only associated to a 'jeq' and is set to 'false' by default.
! Read full context details in the 'jeq' section. If set to 'true',
! after tagged data is sent for accounting the tag is reset making
! in practice this feature mutually exclusive with a 'stack' one.
! 'stack' Currently '+' (ie. sum symbol) is the unique supported value. This
! key makes sense only if JEQs are in use. When matching, accumulate
! tags, using the specified operator/function. By setting 'stack=+',
! the resulting tag would be: <tag>=<previous ID + current ID>.
!
!
! A few examples NetFlow-related. The format of the rules is the same of 'sfacctd' ones
! but some keys don't apply to it. Note that the format of 'pmacctd' rules is slightly
! different.
!
id=1 ip=192.168.2.1 in=4
id=10 ip=192.168.1.1 in=5 out=3
id=11 ip=192.168.1.1 in=3 out=5
id=12 ip=192.168.1.1 in=3
id=13 ip=192.168.1.1 nexthop=10.0.0.254
id=14 ip=192.168.1.1 engine_type=1 engine_id=0
id=15 ip=192.168.1.1 in=3 filter='src net 192.168.0.0/24'
!
! The following rule applies to 'pmacctd'; it will return an error if applied to either
! 'nfacctd' or 'sfacctd'
!
id=21 filter='src net 192.168.0.0/16'
!
! A few examples sFlow-related. The format of the rules is the same of 'nfacctd' ones
! but some keys don't apply to it. Note that the format of 'pmacctd' rules differs.
!
id=30 ip=192.168.1.1
id=31 ip=192.168.1.1 out=50
id=32 ip=192.168.1.1 out=50 agent_id=0 sampling_rate=512
!
! === JEQ example #1:
! - implicit 'return' defaults to false
! - 'id' used to store input interface tags
! - 'id2' used to store output interface tags
!
id=1000 ip=192.168.1.1 in=1 jeq=eval_out
id=1001 ip=192.168.1.1 in=2 jeq=eval_out
id=1002 ip=192.168.1.1 in=3 jeq=eval_out
! ... further INs
id2=1000 ip=192.168.1.1 out=1 label=eval_out
id2=1001 ip=192.168.1.1 out=2
id2=1002 ip=192.168.1.1 out=3
! ... further OUTs
!
! ===
!
! === JEQ example #2:
! - implicit 'return' defaults to false
! - 'id' structured hierarchically to store both input and output interface tags
!
id=11000 ip=192.168.1.1 in=1 jeq=eval_out
id=12000 ip=192.168.1.1 in=2 jeq=eval_out
id=13000 ip=192.168.1.1 in=3 jeq=eval_out
! ... further INs
id=100 ip=192.168.1.1 out=1 label=eval_out stack=+
id=101 ip=192.168.1.1 out=2 stack=+
id=102 ip=192.168.1.1 out=3 stack=+
! ... further OUTs
!
! ===
!
! === JEQ example #3:
! - 'return' set to true: upon matching, the packet is passed to the plugins along with its tag.
! The pre_tag_map flow continues by following up the JEQ.
! - The above leads to duplicates. Hence a pre_tag_filter should be used to split packets among plugins.
! - 'id' used to temporarily store both input and output interface tags
!
id=1001 ip=192.168.1.1 in=1 jeq=eval_out return=true
id=1002 ip=192.168.1.1 in=2 jeq=eval_out return=true
id=1003 ip=192.168.1.1 in=3 jeq=eval_out return=true
! ... further INs
id=2001 ip=192.168.1.1 out=1 label=eval_out
id=2002 ip=192.168.1.1 out=2
id=2003 ip=192.168.1.1 out=3
! ... further OUTs
!
! pre_tag_filter[in]: 1001-1003
! pre_tag_filter[out]: 2001-2003
!
! ===