1TRAFFIC_REPLAY(7)                User Commands               TRAFFIC_REPLAY(7)
2
3
4

NAME

6       traffic_replay - Samba traffic generation tool.
7

SYNOPSIS

9       traffic_replay [-F, --fixed-password <test-password>]
10        [-S, --scale-traffic <scale by factor>]
11        [-r, --replay-rate <scale by factor>] [-D, --duration <seconds>]
12        [--traffic-summary <output file>] [-I, --instance-id <id>]
13        [-K, --prefer-kerberos] [-B, --badpassword-frequency <frequency>]
14        [--dns-rate <rate>] [-t, --timing-data <file>] [-U, --username user]
15        [--password <password>] [-W --workgroup <workgroup>] [--realm <realm>]
16        [-s, --config-file <file>] [-k, --kerberos <kerberos>]
17        [--ipaddress <address>] [-P, --machine-pass] [--option <option>]
18        [-d, --debuglevel <debug level>] {summary-file} {dns-hostname}
19
20       traffic_replay [-G, --generate-users-only]
21        [-F, --fixed-password <test-password>]
22        [-n, --number-of-users <total users>]
23        [--number-of-groups <total groups>]
24        [--average-groups-per-user <average number>]
25        [--group-memberships <total memberships>] {dns-hostname}
26
27       traffic_replay {-c|--clean-up} {dns-hostname}
28
29       traffic_replay [-h, --help] [-V, --version]
30

DESCRIPTION

32       This tool is part of the samba(7) suite.
33
34       This tool generates traffic in order to measure the performance of a
35       Samba DC, and to test how well Samba will scale as a network increases
36       in size. It can simulate multiple different hosts making multiple
37       different types of requests to a DC.
38
39       This tool is intended to run against a dedicated test DC (rather than a
40       live DC that is handling real network traffic).
41
42       Note that a side-effect of running this tool is that user accounts will
43       be created on the DC, in order to test various Samba operations. As
44       creating accounts can be very time-consuming, these users will remain
45       on the DC by default. To remove these accounts, use the --clean-up
46       option.
47

OPTIONS

49       -h|--help
50           Print a summary of command line options.
51
52       summary-file
53           File containing the network traffic to replay. This should either
54           be a traffic-summary (generated by traffic_summary.pl) or a
55           traffic-model (generated by traffic_learner). Based on this file,
56           this tool will generate 'conversations' which represent Samba
57           activity between a network host and the DC.
58
59       dns-hostname
60           The full DNS hostname of the DC that's being tested. The Samba
61           activity in the summary-file will be replicated and directed at
62           this DC. It's recommended that you use a dedicated DC for testing
63           and don't try to run this tool against a DC that's processing live
64           network traffic.
65
66       -F|--fixed-password <test-password>
67           Test users are created when this tool is run, so that actual Samba
68           activity, such as authorizing users, can be mimicked. This option
69           specifies the password that will be used for any test users that
70           are created.
71
72           Note that any users created by this tool will remain on the DC
73           until you run the --clean-up option. Therefore, the fixed-password
74           option needs to be the same each time the tool is run, otherwise
75           the test users won't authenticate correctly.
76
77       Traffic Model Options
78           When the summary-file is a traffic-model (produced by
79           traffic_learner), use these options to alter the traffic that gets
80           generated.
81
82           -D|--duration <seconds>
83               Specifies the approximate duration in seconds to generate
84               traffic for. The default is 60 seconds.
85
86           -r|--replay-rate <factor>
87               Replays the traffic faster by this factor. This option won't
88               affect the number of conversations (which is based on the
89               traffic model), but the rate at which the packets are sent will
90               be increased.
91
92           -S|--scale-traffic <factor>
93               Increases the number of conversations by this factor. This
94               option won't affect the rate at which packets get sent (which
95               is still based on the traffic model), but it will mean more
96               conversations get replayed.
97
98           --traffic-summary <output-file>
99               Instead of replaying a traffic-model, this option generates a
100               traffic-summary file based on what traffic would be sent. Using
101               a traffic-model allows you to scale the packet rate and number
102               of packets sent. However, using a traffic-model introduces some
103               randomness into the traffic generation. So running the same
104               traffic_replay command multiple times using a model file may
105               result in some differences in the actual traffic sent. However,
106               running the same traffic_replay command multiple times with a
107               traffic-summary file will always result in the same traffic
108               being sent.
109
110               For taking performance measurements over several test runs,
111               it's recommended to use this option and replay the traffic from
112               a traffic-summary file.
113
114
115       --generate-users-only
116           Add extra user/groups on the DC to increase the DB size. By
117           default, this tool automatically creates test users that map to the
118           traffic conversations being generated. This option allows extra
119           users to be created on top of this. Note that these extra users may
120           not actually used for traffic generation - the traffic generation
121           is still based on the number of conversations from the
122           model/summary file.
123
124           Generating a large number of users can take a long time, so it this
125           option allows this to be done only once.
126
127           Note that the users created will remain on the DC until the tool is
128           run with the --clean-up option. This means that it is best to only
129           assign group memberships once, i.e. run --clean-up before assigning
130           a different allocation of group memberships.
131
132           -n|--number-of-users <total-users>
133               Specifies the total number of test users to create (excluding
134               any machine accounts required for the traffic). Note that these
135               extra users simply populate the DC's DB - the actual user
136               traffic generated is still based on the summary-file.
137
138           --number-of-groups <total-groups>
139               Creates the specified number of groups, for assigning the test
140               users to. Note that users are not automatically assigned to
141               groups - use either --average-groups-per-user or
142               --group-membership to do this.
143
144           --average-groups-per-user <average-groups>
145               Randomly assigns the test users to the test groups created. The
146               group memberships are distributed so that the overall average
147               groups that a user is member of matches this number. Some users
148               will belong to more groups and some users will belong to fewer
149               groups. This option is incompatible with the --group-membership
150               option.
151
152           --group-memberships <total-memberships>
153               Randomly assigns the test users to the test groups created. The
154               group memberships are distributed so that the total groups that
155               a user is member of, across all users, matches this number. For
156               example, with 100 users and 10 groups, --group-memberships=300
157               would assign a user to 3 groups on average. Some users will
158               belong to more groups and some users will belong to fewer
159               groups, but the total of all member linked attributes would be
160               300. This option is incompatible with the --group-membership
161               option.
162
163
164       --clean-up
165           Cleans up any users and groups that were created by previously
166           running this tool. It is recommended you always clean up after
167           running the tool.
168
169       -I|--instance-id <id>
170           Use this option to run multiple instances of the tool on the same
171           DC at the same time. This adds a prefix to the test users generated
172           to keep them separate on the DC.
173
174       -K|--prefer-kerberos
175           Use Kerberos to authenticate the test users.
176
177       -B|--badpassword-frequency <frequency>
178           Use this option to simulate users trying to authenticate with an
179           incorrect password.
180
181       --dns-rate <rate>
182           Increase the rate at which DNS packets get sent.
183
184       -t|--timing-data <file>
185           This writes extra timing data to the file specified. This is mostly
186           used for reporting options, such as generating graphs.
187
188       Samba Common Options
189
190           -d|--debuglevel=level
191               level is an integer from 0 to 10. The default value if this
192               parameter is not specified is 1.
193
194               The higher this value, the more detail will be logged to the
195               log files about the activities of the server. At level 0, only
196               critical errors and serious warnings will be logged. Level 1 is
197               a reasonable level for day-to-day running - it generates a
198               small amount of information about operations carried out.
199
200               Levels above 1 will generate considerable amounts of log data,
201               and should only be used when investigating a problem. Levels
202               above 3 are designed for use only by developers and generate
203               HUGE amounts of log data, most of which is extremely cryptic.
204
205               Note that specifying this parameter here will override the log
206               level parameter in the smb.conf file.
207
208           -s|--configfile=<configuration file>
209               The file specified contains the configuration details required
210               by the server. The information in this file includes
211               server-specific information such as what printcap file to use,
212               as well as descriptions of all the services that the server is
213               to provide. See smb.conf for more information. The default
214               configuration file name is determined at compile time.
215
216           --option=<name>=<value>
217               Set the smb.conf(5) option "<name>" to value "<value>" from the
218               command line. This overrides compiled-in defaults and options
219               read from the configuration file.
220
221           --realm=REALM
222               Set the realm name
223
224           -V|--version
225               Prints the program version number.
226
227
228       Credential Options
229
230           --simple-bind-dn=DN
231               DN to use for a simple bind
232
233           --password=PASSWORD
234               Password
235
236           -U USERNAME|--username=USERNAME
237               Username
238
239           -W WORKGROUP|--workgroup=WORKGROUP
240               Workgroup
241
242           -k|--kerberos
243               Try to authenticate with kerberos. Only useful in an Active
244               Directory environment.
245
246           --ipaddress=IPADDRESS
247               IP address of the server
248
249           -P|--machine-pass
250               Use stored machine account password.
251
252

OPERATIONS

254   Generating a traffic-summary file
255       To use this tool, you need either a traffic-summary file or a
256       traffic-model file. To generate either of these files, you will need a
257       packet capture of actual Samba activity on your network.
258
259       Use Wireshark to take a packet capture on your network of the traffic
260       you want to generate. For example, if you want to simulate lots of
261       users logging on, then take a capture at 8:30am when users are logging
262       in.
263
264       Next, you need to convert your packet capture into a traffic summary
265       file, using traffic_summary.pl. Basically this removes any sensitive
266       information from the capture and summarizes what type of packet was
267       sent and when.
268
269       Refer to the traffic_summary.pl --help help for more details, but the
270       basic command will look something like:
271
272       tshark -r capture.pcapng -T pdml | traffic_summary.pl >
273       traffic-summary.txt
274
275   Replaying a traffic-summary file
276       Once you have a traffic-summary file, you can use it to generate
277       traffic. The traffic_replay tool gets passed the traffic-summary file,
278       along with the full DNS hostname of the DC being tested. You also need
279       to provide some user credentials, and possibly the Samba realm and
280       workgroup (although the realm and workgroup may be determined
281       automatically, for example from the /etc/smb.conf file, if one is
282       present). E.g.
283
284       traffic_replay traffic-summary.txt my-dc.samdom.example.com
285       -UAdmin%password -W samdom --realm=samdom.example.com
286       --fixed-password=blahblah123!
287
288       This simply regenerates Samba activity seen in the traffic summary. The
289       traffic is grouped into 'conversations' between a host and the DC. A
290       user and machine account is created on the DC for each conversation, in
291       order to allow logon and other operations to succeed. The script
292       generates the same types of packets as those seen in the summary.
293
294       Creating users can be quite a time-consuming process, especially if a
295       lot of conversations are being generated. To save time, the test users
296       remain on the DC by default. You will need to run the --clean-up option
297       to remove them, once you have finished generating traffic. Because the
298       same test users are used across multiple runs of the tool, a consistent
299       password for these users needs to be used - this is specified by the
300       --fixed-password option.
301
302       The benefit of this tool over simply using tcprelay is that the traffic
303       generated is independent of any specific network. No setup is needed
304       beforehand on the test DC. The traffic no longer contains sensitive
305       details, so the traffic summary could be potentially shared with other
306       Samba developers.
307
308       However, replaying a traffic-summary directly is somewhat limited in
309       what you can actually do. A more flexible approach is to generate the
310       traffic using a model file.
311
312   Generating a traffic-model file
313       To create a traffic-model file, simply pass the traffic-summary file to
314       the traffic_learner script. E.g.
315
316       traffic_learner traffic-summary.txt -o traffic-model.txt
317
318       This generates a model of the Samba activity in your network. This
319       model-file can now be used to generate traffic.
320
321   Replaying the traffic-model file
322       Packet generation using a traffic-model file uses the same command as a
323       traffic-summary file, e.g.
324
325       traffic_replay traffic-model.txt my-dc.samdom.example.com
326       -UAdmin%password
327
328       By default, this will generate 60 seconds worth of traffic based on the
329       model. You can specify longer using the --duration parameter.
330
331       The traffic generated is an approximation of what was seen in the
332       network capture. The traffic generation involves some randomness, so
333       running the same command multiple times may result in slightly
334       different traffic being generated.
335
336       As well as changing how long the model runs for, you can also change
337       how many conversations get generated and how fast the traffic gets
338       replayed. To roughly double the number of conversations that get
339       replayed, use --scale-traffic=2 or to approximately halve the number
340       use --scale-traffic=0.5. To approximately double how quickly the
341       conversations get replayed, use --replay-rate=2, or to halve this use
342       --replay-rate=0.5
343
344       For example, to generate approximately 10 times the amount of traffic
345       seen over a two-minute period (based on the network capture), use:
346
347       traffic_replay traffic-model.txt my-dc.samdom.example.com
348       -UAdmin%password --fixed-password=blahblah123! --scale-traffic=10
349       --duration=120
350
351   Scaling the number of users
352       The performance of a Samba DC running a small subset of test users will
353       be different to a fully-populated Samba DC running in a network. As the
354       number of users increases, the size of the DB increases, and a very
355       large DB will perform worse than a smaller DB.
356
357       To increase the size of the Samba DB, this tool can also create extra
358       users and groups. These extra users are basically 'filler' for the DB.
359       They won't actually be used to generate traffic, but they may slow down
360       authentication of the test users.
361
362       For example, to populate the DB with an extra 5000 users (note this
363       will take a while), use the command:
364
365       traffic_replay my-dc.samdom.example.com -UAdmin%password
366       --generate-users-only --fixed-password=blahblah123!
367       --number-of-users=5000
368
369       You can also create groups and assign users to groups. The users can be
370       randomly assigned to groups - this includes any extra users created as
371       well as the users that map to conversations. Use either
372       --average-groups-per-user or --group-memberships to specify how many
373       group memberships should be assigned to the test users.
374
375       For example, to assign the users in the replayed conversations into 10
376       groups on average, use a command like:
377
378       traffic_replay traffic-model.txt my-dc.samdom.example.com
379       -UAdmin%password --fixed-password=blahblah123! --generate-users-only
380       --number-of-groups=25 --average-groups-per-user=10
381
382       The users created by the test will have names like STGU-0-xyz. The
383       groups generated have names like STGG-0-xyz.
384

VERSION

386       This man page is complete for version 4.8.3 of the Samba suite.
387

SEE ALSO

389       traffic_learner(7).
390

AUTHOR

392       The original Samba software and related utilities were created by
393       Andrew Tridgell. Samba is now developed by the Samba Team as an Open
394       Source project similar to the way the Linux kernel is developed.
395
396       The traffic_replay tool was developed by the Samba team at Catalyst IT
397       Ltd.
398
399       The traffic_replay manpage was written by Tim Beale.
400
401
402
403Samba 4.8.3                       10/30/2018                 TRAFFIC_REPLAY(7)
Impressum