| 262 | | == (5) Generate Regular and Intrusion Traffic == |
| 263 | | |
| 264 | | 1. In a separate window for destination, start the netcat server by running: |
| 265 | | |
| 266 | | - ''' nc -u -l 5000 ''' |
| 267 | | |
| 268 | | 2. In another separate window for s1, start the netcat client by running: |
| 269 | | |
| 270 | | - ''' nc -u destination 5000''' |
| 271 | | |
| 272 | | 3. Type something on the s1 window and you should see it on the destination window. |
| 273 | | |
| 274 | | 4. In another separate window for s1, we will generate attack traffic, which in our case are ICMP messages. To send ICMP messages to the destination, run the following ping command: |
| 275 | | |
| 276 | | - ''' ping destination''' |
| 277 | | |
| 278 | | The first few ping messages are able to reach destination since it takes some time for the controller to get the intrusion detection results from the VNFs via the RINA distributed application, but after a few seconds, all following ping messages will not be able to reach the destination, and you should see the following output: |
| 279 | | |
| 280 | | {{{ |
| 281 | | #!html |
| 282 | | <img src="http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/pics/failedPing.png" hspace=50> |
| 283 | | }}} |
| 284 | | |
| 285 | | 5. Type something on the s1 window for netcat and you should NOT see it on the destination window. If you go to the controller window which runs the Ryu controller, you can see that all traffic from the attacker is dropped with the following output: |
| 286 | | |
| 287 | | {{{ |
| 288 | | #!html |
| 289 | | <img src="http://csr.bu.edu/rina/grw-bu2016/nfv_ryu/pics/intrusion.png" hspace=50> |
| 290 | | }}} |
| 291 | | |
| 292 | | 6. Restart the netcat server on the destination by running: |
| 293 | | |
| 294 | | - ''' nc -u -l 5000 ''' |
| 295 | | |
| 296 | | 7. In another separate window for s2, start the netcat client by running: |
| 297 | | |
| 298 | | - ''' nc -u destination 5000''' |
| 299 | | |
| 300 | | Notice that using the netcat client side on s2, all messages are able to reach the destination since s2 traffic is not blocked. However, no traffic from s1 reaches the destination since s1 is blocked. |
| | 262 | == (6) Generate background traffic |
| | 263 | |
| | 264 | 1. We will use the iperf application to generate flows between a source and destination. If iperf is not installed on your nodes, execute |
| | 265 | |
| | 266 | ''' sudo apt-get install iperf ''' |
| | 267 | |
| | 268 | 2. Run iperf server on the destination node: |
| | 269 | |
| | 270 | '''iperf -u -s ''' |
| | 271 | |
| | 272 | 3. Now we will generate traffic from the sources 1 (s1) to the destination node using iperf and see how it effects the CPU utilization at VNF1 and VNF2 running Snort IDS. Note that if we run multiple instances of iperf, we can generate significant load on the VNF instances. To run iperf client on a source, execute: |
| | 273 | |
| | 274 | ''' iperf -u -c destination -t 500 & ''' |
| | 275 | |
| | 276 | {{{ |
| | 277 | #!html |
| | 278 | <table id="Table_02" width = "1150" border="0" cellpadding="0" cellspacing="10" > |
| | 279 | <tr> |
| | 280 | <td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image068.gif" > </td> |
| | 281 | <td> <i>Note that you can run multiple instances of iperf by running <span style="background:#c0c0c0"> iperf -c destination -t 500 & </span> multiple times in s1 and s2 nodes. This flow lasts for 500 seconds. For this experiment, you may try to run 2-3 iperf instances. To kill all the flows generated at a node, run <span style="background:#c0c0c0"> killall –v iperf </span> </i> |
| | 282 | </td></tr></table> |
| | 283 | }}} |
| | 284 | |
| | 285 | |
