SIGCOMM 2019 Tutorial Edits (p4lang#272)

* Updated the utils/run_exercise.py to allow exercises to customize
host configuration from the topology.json file.

Now hosts and `ping` each other in the basic exercise. Other Linux
utilities should work as well (e.g. iperf).

```
mininet> h1 ping h2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=62 time=3.11 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=62 time=2.34 ms
64 bytes from 10.0.2.2: icmp_seq=3 ttl=62 time=2.15 ms
^C
--- 10.0.2.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 2.153/2.540/3.118/0.416 ms
mininet> pingall
*** Ping: testing ping reachability
h1 -> h2 h3
h2 -> h1 h3
h3 -> h1 h2
*** Results: 0% dropped (6/6 received)
```

Only updated basic exercise, still need to update other exercises.

Also, updated the root-bootstrap.sh because I was running into issues
with latest version of vagrant.

* Accidentially added the solution to the basic exercise in the previous
commit. Undoing that here ...

* Updated the topology.json file and table entries for the basic_tunnel
exercise.

* Updated P4Runtime exercise with new topology and table entries.

* Fixed MAC addresses in P4Runtime exercise. It is working now.

* Fixed MAC addresses in P4Runtime exercise starter code

* Updated ECN exercise to use new topology.json file. Updated the
table entries / MAC addresses as well.

* Updated the topology.json file and table entries for the MRI exercise.

* Updated source_routing exercise with new topology file and verified
correct functionality.

* Updated load_balance exercise with new topology.

* Moved basic exercise triangle topology into a separate folder

* Added new topology for the basic exercise: a single pod of a fat-tree.

* Updated Makefiles and run_exercise.py to allow exercises to configure
each switch with a different P4 program. This is mainly for the
firewall exercise.

* Updated Makefiles of project to work with new utils/Makefile

* Updated load_balance and p4runtime exercise Makefiles

* Initial commit of the firewall exercise, which is a simple stateful
firewall that uses a bloom filter. Need to update README files

* Initial commit of the path_monitor exercise. It is working but still
need to update the README and figure out what we want the tutorial
attendees to implement.

* Updated README file in firewall exercise. Also removed the bits
from the starter code that we want the tutorial attendees to
implement

* Renamed path_monitor exercise to link_monitor

* Updated the README in the link_monitor exercise and removed the
bits from the starter code that we want the tutorial attendees
to implement.

* Updated README for the firewall exercise

* Adding pod-topo.png image to basic exercise

* Added firewall-topo.png image to firewall exercise

* Added link-monitor-topo.png to link_monitor exercise

* Updated README files to point to topology images

* Updated top-level README to point to new exercises.

* Fixed link for VM dependencies script in README

* Updated bmv2/pi/p4c commits

* Updated README files for exercises to fix some typos and added
a note about the V1Model architecture.

* Added a note about food for thought in the link_monitor README

* Updated the firewall.p4 program to use two register arrays rather
than a single one. This is to make the design more portable to
high line rate devices which can only support a single access
to each register array.

* Minor fix to firewall exercise to get rid of compiler warning.

* Updated comment in firewall exercise.

* Minor (typo) fixes in the firewall ReadMe

* More info in firewall exercise ReadMe step 2

* Updated firewall.p4 to reuse direction variable

* More testing steps, small fixes in firewall exercise Readme

* Added food for thought to firewall Readme

* Cosmetic fixes to firewall ReadMe

* Made a few updates to the basic exercise README and added more
details to the link_monitor exercise README.

Also added a command to install grip when provisioning the VM.
This could be useful for rendering the markdown README files offline.

* Updated top level README so it can be merged into the master branch.

* Moved cmd to install grip from root-bootstrap to user-bootstrap

Author: sibanez12

README.md

@@ -21,6 +21,10 @@ you get started with P4 programming, organized into several modules:
 * [Calculator](./exercises/other/calc)
 * [Load Balancing](./exercises/load_balance)
 
+5. Stateful Packet Processing
+* [Firewall](./exercises/firewall)
+* [Link Monitoring](./exercises/link_monitor)
+
 ## Presentation 
 
 The slides are available [online](http://bit.ly/p4d2-2018-spring) and
@@ -31,9 +35,10 @@ which contains various examples that you can refer to.
 
 ## Obtaining required software
 
-If you are starting this tutorial at the Spring 2018 P4 Developer Day,
+If you are starting this tutorial at one of the proctored tutorial events,
 then we've already provided you with a virtual machine that has all of
-the required software installed.
+the required software installed. Ask an instructor for a USB stick with
+the VM image.
 
 Otherwise, to complete the exercises, you will need to either build a
 virtual machine or install several dependencies.
@@ -47,11 +52,11 @@ To build the virtual machine:
 - When the machine reboots, you should have a graphical desktop machine with the required
 software pre-installed.
 
-*Note: Before running the `vagrant up` command, make sure you have enabled virtualization in your environment; otherwise you may get a "VT-x is disabled in the BIOS for both all CPU modes" error. Check [this](https://stackoverflow.com/questions/33304393/vt-x-is-disabled-in-the-bios-for-both-all-cpu-modes-verr-vmx-msr-all-vmx-disabl) for enabling it in virtualbox and/or BIOS for different system configurations.
+*Note*: Before running the `vagrant up` command, make sure you have enabled virtualization in your environment; otherwise you may get a "VT-x is disabled in the BIOS for both all CPU modes" error. Check [this](https://stackoverflow.com/questions/33304393/vt-x-is-disabled-in-the-bios-for-both-all-cpu-modes-verr-vmx-msr-all-vmx-disabl) for enabling it in virtualbox and/or BIOS for different system configurations.
 
-You will need the script to execute to completion before you can see the `p4` login on your virtual machine's GUI. In some cases, the `vagrant up` command brings up only the default `vagrant` login with the password `vagrant`. Dependencies may or may not have been installed for you to proceed with running P4 programs. Please refer the existing issues to help fix your problem or create a new one if your specific problem isn't addressed there.*
+You will need the script to execute to completion before you can see the `p4` login on your virtual machine's GUI. In some cases, the `vagrant up` command brings up only the default `vagrant` login with the password `vagrant`. Dependencies may or may not have been installed for you to proceed with running P4 programs. Please refer the [existing issues](https://github.com/p4lang/tutorials/issues) to help fix your problem or create a new one if your specific problem isn't addressed there.
 
-To install dependencies by hand, please reference the [vm](../vm) installation scripts.
+To install dependencies by hand, please reference the [vm](./vm) installation scripts.
 They contain the dependencies, versions, and installation procedure.
 You should be able to run them directly on an Ubuntu 16.04 machine:
 - `sudo ./root-bootstrap.sh`

exercises/basic/Makefile

@@ -1,5 +1,4 @@
 BMV2_SWITCH_EXE = simple_switch_grpc
-NO_P4 = true
-P4C_ARGS = --p4runtime-files $(basename $@).p4.p4info.txt
+TOPO = pod-topo/topology.json
 
 include ../../utils/Makefile

exercises/basic/README.md

@@ -17,6 +17,17 @@ MAC address and output port for the next hop. We have already defined
 the control plane rules, so you only need to implement the data plane
 logic of your P4 program.
 
+We will use the following topology for this exercise. It is a single
+pod of a fat-tree topology and henceforth referred to as pod-topo:
+![pod-topo](./pod-topo/pod-topo.png)
+
+Our P4 program will be written for the V1Model architecture implemented
+on P4.org's bmv2 software switch. The architecture file for the V1Model
+can be found at: /usr/local/share/p4c/p4include/v1model.p4. This file
+desribes the interfaces of the P4 programmable elements in the architecture,
+the supported externs, as well as the architecture's standard metadata
+fields. We encourage you to take a look at it.
+
 > **Spoiler alert:** There is a reference solution in the `solution`
 > sub-directory. Feel free to compare your implementation to the
 > reference.
@@ -36,27 +47,18 @@ up a switch in Mininet to test its behavior.
    ```
    This will:
    * compile `basic.p4`, and
-   * start a Mininet instance with three switches (`s1`, `s2`, `s3`)
-     configured in a triangle, each connected to one host (`h1`, `h2`,
-     and `h3`).
-   * The hosts are assigned IPs of `10.0.1.1`, `10.0.2.2`, and `10.0.3.3`.
+   * start the pod-topo in Mininet and configure all switches with
+   the appropriate P4 program + table entries, and
+   * configure all hosts with the commands listed in
+   [pod-topo/topology.json](./pod-topo/topology.json)
 
-2. You should now see a Mininet command prompt. Open two terminals
-for `h1` and `h2`, respectively:
-   ```bash
-   mininet> xterm h1 h2
-   ```
-3. Each host includes a small Python-based messaging client and
-server. In `h2`'s xterm, start the server:
+2. You should now see a Mininet command prompt. Try to ping between
+   hosts in the topology:
    ```bash
-   ./receive.py
+   mininet> h1 ping h2
+   mininet> pingall
    ```
-4. In `h1`'s xterm, send a message to `h2`:
-   ```bash
-   ./send.py 10.0.2.2 "P4 is cool"
-   ```
-   The message will not be received.
-5. Type `exit` to leave each xterm and the Mininet command line.
+3. Type `exit` to leave each xterm and the Mininet command line.
    Then, to stop mininet:
    ```bash
    make stop
@@ -66,7 +68,7 @@ server. In `h2`'s xterm, start the server:
    make clean
    ```
 
-The message was not received because each switch is programmed
+The ping failed because each switch is programmed
 according to `basic.p4`, which drops all packets on arrival.
 Your job is to extend this file so it forwards packets.
 
@@ -77,7 +79,7 @@ within each table are inserted by the control plane. When a rule
 matches a packet, its action is invoked with parameters supplied by
 the control plane as part of the rule.
 
-In this exercise, we have already implemented the the control plane
+In this exercise, we have already implemented the control plane
 logic for you. As part of bringing up the Mininet instance, the
 `make run` command will install packet-processing rules in the tables of
 each switch. These are defined in the `sX-runtime.json` files, where
@@ -86,7 +88,7 @@ each switch. These are defined in the `sX-runtime.json` files, where
 **Important:** We use P4Runtime to install the control plane rules. The
 content of files `sX-runtime.json` refer to specific names of tables, keys, and
 actions, as defined in the P4Info file produced by the compiler (look for the
-file `build/basic.p4info` after executing `make run`). Any changes in the P4
+file `build/basic.p4.p4info.txt` after executing `make run`). Any changes in the P4
 program that add or rename tables, keys, or actions will need to be reflected in
 these `sX-runtime.json` files.
 
@@ -120,20 +122,22 @@ A complete `basic.p4` will contain the following components:
 
 ## Step 3: Run your solution
 
-Follow the instructions from Step 1. This time, your message from
-`h1` should be delivered to `h2`.
+Follow the instructions from Step 1. This time, you should be able to
+sucessfully ping between any two hosts in the topology. 
 
 ### Food for thought
 
-The "test suite" for your solution---sending a message from `h1` to
-`h2`---is not very robust. What else should you test to be confident
-of your implementation?
+The "test suite" for your solution---sending pings between hosts in the
+topology---is not very robust. What else should you test to be confident
+that you implementation is correct?
 
 > Although the Python `scapy` library is outside the scope of this tutorial,
 > it can be used to generate packets for testing. The `send.py` file shows how
 > to use it.
 
 Other questions to consider:
+ - How would you enhance your program to respond to ARP requests?
+ - How would you enhance your program to support traceroute?
  - How would you enhance your program to support next hops?
  - Is this program enough to replace a router?  What's missing?
 
@@ -152,7 +156,7 @@ messages to fix your `basic.p4` implementation.
 
 3. `basic.p4` might compile, and the control plane rules might be
 installed, but the switch might not process packets in the desired
-way. The `/tmp/p4s.<switch-name>.log` files contain detailed logs
+way. The `logs/sX.log` files contain detailed logs
 that describing how each switch processes each packet. The output is
 detailed and can help pinpoint logic errors in your implementation.
 
@@ -166,9 +170,3 @@ these instances:
 make stop
 ```
 
-## Next Steps
-
-Congratulations, your implementation works! In the next exercise we
-will build on top of this and add support for a basic tunneling
-protocol: [basic_tunnel](../basic_tunnel)!
-

exercises/basic/pod-topo/pod-topo.png

@@ -0,0 +1,57 @@
+{
+  "target": "bmv2",
+  "p4info": "build/basic.p4.p4info.txt",
+  "bmv2_json": "build/basic.json",
+  "table_entries": [
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "default_action": true,
+      "action_name": "MyIngress.drop",
+      "action_params": { }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.1.1", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:01:11",
+        "port": 1
+      }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.2.2", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:02:22",
+        "port": 2
+      }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.3.3", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:03:00",
+        "port": 3
+      }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.4.4", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:04:00",
+        "port": 4
+      }
+    }
+  ]
+}

exercises/basic/pod-topo/s1-runtime.json

@@ -0,0 +1,57 @@
+{
+  "target": "bmv2",
+  "p4info": "build/basic.p4.p4info.txt",
+  "bmv2_json": "build/basic.json",
+  "table_entries": [
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "default_action": true,
+      "action_name": "MyIngress.drop",
+      "action_params": { }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.1.1", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:03:00",
+        "port": 4
+      }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.2.2", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:04:00",
+        "port": 3
+      }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.3.3", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:03:33",
+        "port": 1
+      }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.4.4", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:04:44",
+        "port": 2
+      }
+    }
+  ]
+}

exercises/basic/pod-topo/s2-runtime.json

@@ -0,0 +1,57 @@
+{
+  "target": "bmv2",
+  "p4info": "build/basic.p4.p4info.txt",
+  "bmv2_json": "build/basic.json",
+  "table_entries": [
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "default_action": true,
+      "action_name": "MyIngress.drop",
+      "action_params": { }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.1.1", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:01:00",
+        "port": 1
+      }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.2.2", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:01:00",
+        "port": 1
+      }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.3.3", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:02:00",
+        "port": 2
+      }
+    },
+    {
+      "table": "MyIngress.ipv4_lpm",
+      "match": {
+        "hdr.ipv4.dstAddr": ["10.0.4.4", 32]
+      },
+      "action_name": "MyIngress.ipv4_forward",
+      "action_params": {
+        "dstAddr": "08:00:00:00:02:00",
+        "port": 2
+      }
+    }
+  ]
+}