| 215 | | |
| 216 | | == (4) Run Snort and Generate Traffic == |
| 217 | | |
| 218 | | 1. First we will run Snort IDS on VNF1 and VNF2. In separate windows for VNF1 and VNF2, execute the following command: |
| 219 | | |
| 220 | | - '''sudo /usr/local/bin/snort -A full -dev -i eth1''' |
| 221 | | |
| 222 | | |
| 223 | | |
| 224 | | 2. We will use the iperf application to generate flows between a source and destination. If iperf is not installed on your nodes, execute: |
| 225 | | |
| 226 | | - ''' sudo apt-get install iperf ''' |
| 227 | | |
| 228 | | |
| 229 | | 3. Run iperf server on the destination node: |
| 230 | | |
| 231 | | - ''' iperf -u -s ''' |
| 232 | | |
| 233 | | |
| 234 | | 4. Now we will generate traffic from the sources (s1 and s2) 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: |
| 235 | | |
| 236 | | - ''' iperf -u -c destination -t 500 & ''' |
| 237 | | |
| 238 | | {{{ |
| 239 | | #!html |
| 240 | | <table id="Table_02" width = "1150" border="0" cellpadding="0" cellspacing="10" > |
| 241 | | <tr> |
| 242 | | <td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image068.gif" > </td> |
| 243 | | <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> |
| 244 | | </td></tr></table> |
| 245 | | }}} |
| 246 | | |
| 247 | | 5. Now if you look at the controller window, which is running the PI-controller, you can see the load on VNF1 has significantly increased. If the load is more than 30%, some percentage of the traffic flows will be diverted to VNF2. |
| 248 | | |
| 249 | | {{{ |
| 250 | | #!html |
| 251 | | <table id="Table_02" width = "700" border="0" cellpadding="0" cellspacing="10" > |
| 252 | | <tr> |
| 253 | | <td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image022.gif"> </td> |
| 254 | | <td> <b>OPTIONAL: Review the PI Ryu Controller Code</b> </td> </tr></table> |
| 255 | | }}} |
| 256 | | |
| 257 | | |
| 258 | | The Ryu controller gets the load balancing information from the output text file generated by the PI-controller. Based on the value of the control variable (variable X), it sends each new flow to either VNF1 or VNF2. The algorithm for the PI-based OVS controller is shown below. |
| 259 | | |
| 260 | | |
| 261 | | {{{ |
| 262 | | #!html |
| 263 | | <img src="http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image092.gif" hspace=40> |
| 264 | | |
| 265 | | }}} |
| 266 | | |
| 267 | | |
| 268 | | '''Note: You can see in "nfv.config" that the information of the intrusion traffic is located in the file ''/tmp/attacker.txt'' on the controller VM, which is outputted by the RINA distributed application. Make sure the file is empty each time you run this experiment.''' |
