summaryrefslogtreecommitdiffstats
path: root/doc/trex_port_service_mode.asciidoc
blob: f99d63f1e8f782eee0cf52467843c48839d9ba1b (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
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
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
In 'normal operation mode', to preserve high speed processing of packets,
TRex ignores most of the RX traffic, with the exception of counting/statistic and handling
latency flows.


In the following diagram it is illustrated how RX packets are handled.
Only a portion is forwarded to the RX handling module and none of forward back
to the Python client.

image::images/port_normal_mode.png[title="Port Under Normal Mode",align="left",width={p_width}, link="images/port_normal_mode.png"]



We provide another mode called 'service mode' in which a port will respond to ping, ARP requests
and also provide a capabality in this mode to forward packets to the Python control plane for
applying full duplex protocols (DCHP, IPv6 neighboring and etc.)

The following diagram illustrates of packets can be forwarded back to the Python client

image::images/port_service_mode.png[title="Port Under Service Mode",align="left",width={p_width}, link="images/port_service_mode.png"]

In this mode, it is possible to write python plugins for emulation (e.g. IPV6 ND/DHCP) to prepare the setup and then move to normal mode for high speed testing 


*Example Of Switcing Between 'Service' And 'Normal' Mode*
[source,bash]
----

trex(service)>service --help
usage: service [-h] [--port PORTS [PORTS ...] | -a] [--off]

Configures port for service mode. In service mode ports will reply to ARP,
PING and etc.

optional arguments:
  -h, --help            show this help message and exit
  --port PORTS [PORTS ...], -p PORTS [PORTS ...]
                        A list of ports on which to apply the command
  -a                    Set this flag to apply the command on all available
                        ports
  --off                 Deactivates services on port(s)


trex>service

Enabling service mode on port(s) [0, 1]:                     [SUCCESS]

trex(service)>service --off

Disabling service mode on port(s) [0, 1]:                    [SUCCESS]

----

.*Example Of Switcing Between 'Service' And 'Normal' Mode-API*
[source,Python]
----

  client.set_service_mode(ports = [0, 1], enabled = True)
  
  client.set_service_mode(ports = [0, 1], enabled = False)

----

==== ARP / ICMP response
[IMPORTANT]
Only while in service mode, ports will reply to ICMP echo requests and ARP requests.


==== Packet Capturing
[IMPORTANT]
The following section is available only under service mode

While under service mode TRex provides couple of ways to examine
and manipulate both RX and TX packets.


Packet capturing is implemented by allocating one more more fast in-memory queues
on the server side that will copy-and-store the packet buffer.


Each queue can be defined with storage, which ports on either TX/RX it should capture
and whether it should be 'cyclic' or 'fixed'

image::images/packet_capture_arch.png[title="Packet Captruing Architecture",align="left",width={p_width}, link="images/packet_capture_arch.png"]

The above architecture implies that we can 'capture' at high speed for a short amount of time.

For example,
A queue of 1 million packets can be allocated as a cyclic queue and be active under a rate of couple of Mpps.
It effectively provide a sampling of the last 1 million packets seen by the server with the given filters.

==== Packet Capturing API Usage

The Python API usages is fairly simple:

.Python API:
[source,python]
----

# move port 1 to service mode as we want to capture traffic on it
client.set_service_mode(ports = 1)

# start a capture on port 1 RX side with a limit and a mode
capture = client.start_capture(rx_ports = 1, limit = 100, mode = 'fixed')

# execute your code here

# save the packets to a file or to a list (see the Python API docs)
client.stop_capture(capture['id'], '/home/mydir/port_0_rx.pcap')

# exit service mode on port 1
client.set_service_mode(ports = 1, enabled = False)

----

==== Packet Capturing Console Usage

The console provides couple of flexible ways to handle packet capturing

* *Capture Monitoring*
* *Capture Recording*

===== Capture Monitoring
Capture monitoring is a non-persistent way to capture and show packets from either TX / RX
of one or more ports


Monitoring provides 3 modes:

* *Low Verbose*    - short line per packet will be displayed
* *High Verbose*   - a full scapy show will be displayed per packet
* *Wireshark Pipe* - launches Wireshark with a pipe connected to the traffic being captured


In the first two options, packets information will be displayed *on the console*

So for high amount of traffic being monitored, consider *Wireshark Pipe* or the
*Capture Recording*

.*Example of capturing traffic using the console with verbose on*

[source,python]
----
trex>service                                                                  <1>

Enabling service mode on port(s) [0, 1, 2, 3]:               [SUCCESS]      

trex(service)>capture monitor start --rx 3 -v                                 <2>

Starting stdout capture monitor - verbose: 'high'            [SUCCESS]


*** use 'capture monitor stop' to abort capturing... ***

trex(service)>arp -p 3                                                        <3>

Resolving destination on port(s) [3]:                        [SUCCESS]

Port 3 - Recieved ARP reply from: 1.1.1.1, hw: 90:e2:ba:ae:88:b8              <4>
38.14 [ms]

trex(service)>

#1 Port: 3 ?-- RX

    Type: ARP, Size: 60 B, TS: 16.98 [sec]

    ###[ Ethernet ]###
      dst       = 90:e2:ba:af:13:89
      src       = 90:e2:ba:ae:88:b8
      type      = 0x806
    ###[ ARP ]###
         hwtype    = 0x1
         ptype     = 0x800
         hwlen     = 6
         plen      = 4
         op        = is-at                                                    <5>
         hwsrc     = 90:e2:ba:ae:88:b8
         psrc      = 1.1.1.1
         hwdst     = 90:e2:ba:af:13:89
         pdst      = 4.4.4.4
    ###[ Padding ]###
            load      = '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'


trex(service)>
----
<1> Move to *service mode* to allow capturing
<2> Activate a capture monitor on port *3* RX side with *verbose* on
<3> Send an ARP request on port *3*
<4> The console shows the returning packet
<5> *is-at* ARP response was captured



.*Example of capturing traffic using Wireshark pipe*

[source,python]
----
trex(service)>capture monitor start --rx 3 -p                                 <1>

Starting pipe capture monitor                                [SUCCESS]


Trying to locate Wireshark                                   [SUCCESS]


Checking permissions on '/usr/bin/dumpcap'                   [SUCCESS]


Launching '/usr/bin/wireshark -k -i /tmp/tmputa4jf3c'        [SUCCESS]        <2>


Waiting for Wireshark pipe connection                        [SUCCESS]        <3>


*** Capture monitoring started ***                                            <4>

trex(service)>arp                                                             <5>

Resolving destination on port(s) [0, 1, 2, 3]:               [SUCCESS]

Port 0 - Recieved ARP reply from: 4.4.4.4, hw: 90:e2:ba:af:13:89
Port 1 - Recieved ARP reply from: 3.3.3.3, hw: 90:e2:ba:af:13:88
Port 2 - Recieved ARP reply from: 2.2.2.2, hw: 90:e2:ba:ae:88:b9
Port 3 - Recieved ARP reply from: 1.1.1.1, hw: 90:e2:ba:ae:88:b8

----
<1> Activate a monitor using a Wireshark pipe
<2> Try to automatically launch Wireshark with connection the pipe
<3> Console will block until connection was established
<4> Monitor is active
<5> Send ARP request


image::images/capture_wireshark_pipe.png[title="Wireshark Pipe",align="left",width={p_width}, link="images/capture_wireshark_pipe.png"]

===== Capture Recording
In addition to monitoring, the console allows a simple recording as well.

Recording allows the user to define a fixed size queue which then can
be saved to a PCAP file.

.*Example of capturing a traffic to a fixed size queue*

[source,python]
----
trex(service)>capture record start --rx 3 --limit 200                         <1>

Starting packet capturing up to 200 packets                  [SUCCESS]

*** Capturing ID is set to '4' ***                                            <2>
*** Please call 'capture record stop --id 4 -o <out.pcap>' when done ***

trex(service)>capture                                                         <3>

Active Recorders

      ID        |     Status      |     Packets     |      Bytes      |    TX Ports     |    RX Ports
 ------------------------------------------------------------------------------------------------------
       4        |     ACTIVE      |     [0/200]     |       0 B       |        -        |        3



trex(service)>start -f stl/imix.py -m 1kpps -p 0 --force                      <4>

Removing all streams from port(s) [0]:                       [SUCCESS]


Attaching 3 streams to port(s) [0]:                          [SUCCESS]


Starting traffic on port(s) [0]:                             [SUCCESS]

20.42 [ms]

trex(service)>capture                                                         <5>

Active Recorders

      ID        |     Status      |     Packets     |      Bytes      |    TX Ports     |    RX Ports
 ------------------------------------------------------------------------------------------------------
       4        |     ACTIVE      |    [200/200]    |    74.62 KB     |        -        |        3


trex(service)>capture record stop --id 4 -o /tmp/rx_3.pcap                    <6>

Stopping packet capture 4                                    [SUCCESS]


Writing 200 packets to '/tmp/rx_3.pcap'                      [SUCCESS]


Removing PCAP capture 4 from server                          [SUCCESS]

trex(service)>

----

<1> Start a packet record on port *3* RX side with a limit of *200* packets
<2> A new capture was created with an ID *4*
<3> Showing the capture status - currently empty
<4> Start traffic on port *0* which is connected to port *3*
<5> Showing the capture status - full
<6> Save 200 packets to an output file called */tmp/rx_3.pcap*


==== Packet Capturing Video Tutorials 

ifdef::backend-xhtml11[]
++++++++++++++++++

<iframe width="420" height="315"
allowfullscreen="allowfullscreen"
src="https://www.youtube.com/embed/Vsb0A4RNGz0">
</iframe>
++++++++++++++++++
endif::backend-xhtml11[]

The Tutorial shows a little bit of our new packet capture ability