diff --git a/exercises/basic/README.md b/exercises/basic/README.md index b9e85bfe6..53f74e810 100644 --- a/exercises/basic/README.md +++ b/exercises/basic/README.md @@ -10,7 +10,7 @@ With IPv4 forwarding, the switch must perform the following actions for every packet: (i) update the source and destination MAC addresses, (ii) decrement the time-to-live (TTL) in the IP header, and (iii) forward the packet out the appropriate port. - + Your switch will have a single table, which the control plane will populate with static rules. Each rule will map an IP address to the MAC address and output port for the next hop. We have already defined @@ -105,14 +105,14 @@ A complete `basic.p4` will contain the following components: 2. **TODO:** Parsers for Ethernet and IPv4 that populate `ethernet_t` and `ipv4_t` fields. 3. An action to drop a packet, using `mark_to_drop()`. 4. **TODO:** An action (called `ipv4_forward`) that: - 1. Sets the egress port for the next hop. - 2. Updates the ethernet destination address with the address of the next hop. - 3. Updates the ethernet source address with the address of the switch. + 1. Sets the egress port for the next hop. + 2. Updates the ethernet destination address with the address of the next hop. + 3. Updates the ethernet source address with the address of the switch. 4. Decrements the TTL. 5. **TODO:** A control that: 1. Defines a table that will read an IPv4 destination address, and invoke either `drop` or `ipv4_forward`. - 2. An `apply` block that applies the table. + 2. An `apply` block that applies the table. 6. **TODO:** A deparser that selects the order in which fields inserted into the outgoing packet. 7. A `package` instantiation supplied with the parser, control, and deparser. @@ -123,7 +123,7 @@ A complete `basic.p4` will contain the following components: ## Step 3: Run your solution Follow the instructions from Step 1. This time, you should be able to -sucessfully ping between any two hosts in the topology. +sucessfully ping between any two hosts in the topology. ### Food for thought diff --git a/exercises/basic_tunnel/README.md b/exercises/basic_tunnel/README.md index c6aff3264..98bbbec3a 100644 --- a/exercises/basic_tunnel/README.md +++ b/exercises/basic_tunnel/README.md @@ -89,7 +89,7 @@ to hosts. For this step you will need to add your forwarding rules to the 1. In your shell, run: ```bash make run - ``` + ``` This will: * compile `basic_tunnel.p4`, and * start a Mininet instance with three switches (`s1`, `s2`, `s3`) configured @@ -97,39 +97,39 @@ to hosts. For this step you will need to add your forwarding rules to the * The hosts are assigned IPs of `10.0.1.1`, `10.0.2.2`, and `10.0.3.3`. 2. You should now see a Mininet command prompt. Open two terminals for `h1` and -`h2`, respectively: +`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: - ```bash +`h2`'s xterm, start the server: + ```bash ./receive.py ``` 4. First we will test without tunneling. In `h1`'s xterm, send a message to -`h2`: +`h2`: ```bash ./send.py 10.0.2.2 "P4 is cool" ``` - The packet should be received at `h2`. If you examine the received packet + The packet should be received at `h2`. If you examine the received packet you should see that is consists of an Ethernet header, an IP header, a TCP header, and the message. If you change the destination IP address (e.g. try to send to `10.0.3.3`) then the message should not be received by `h2`, and will instead be received by `h3`. -5. Now we test with tunneling. In `h1`'s xterm, send a message to `h2`: +5. Now we test with tunneling. In `h1`'s xterm, send a message to `h2`: ```bash ./send.py 10.0.2.2 "P4 is cool" --dst_id 2 ``` The packet should be received at `h2`. If you examine the received packet you should see that is consists of an Ethernet header, a tunnel header, an IP header, - a TCP header, and the message. -6. In `h1`'s xterm, send a message: + a TCP header, and the message. +6. In `h1`'s xterm, send a message: ```bash ./send.py 10.0.3.3 "P4 is cool" --dst_id 2 ``` The packet should be received at `h2`, even though that IP address is the address of `h3`. This is because the switch is no longer using the IP header for routing - when the `MyTunnel` header is in the packet. + when the `MyTunnel` header is in the packet. 7. Type `exit` or `Ctrl-D` to leave each xterm and the Mininet command line. @@ -169,7 +169,7 @@ implementation or forwarding rules. 3. `basic_tunnel.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..log` files contain detailed logs that describing how +`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. diff --git a/exercises/ecn/README.md b/exercises/ecn/README.md index fbf0f243d..0b1026085 100644 --- a/exercises/ecn/README.md +++ b/exercises/ecn/README.md @@ -103,7 +103,7 @@ A complete `ecn.p4` will contain the following components: 1. Set the egress port for the next hop. 2. Update the ethernet destination address with the address of the next hop. - 3. Update the ethernet source address with the address of the switch. + 3. Update the ethernet source address with the address of the switch. 4. Decrement the TTL. 5. An egress control block that checks the ECN and `standard_metadata.enq_qdepth` and sets the ipv4.ecn. @@ -165,12 +165,12 @@ There are several ways that problems might manifest: error emitted from the compiler and stop. 2. `ecn.p4` compiles but does not support the control plane rules in the `sX-runtime.json` files that `make` tries to install using - a Python controller. In this case, `make` will log the controller output + a Python controller. In this case, `make` will log the controller output in the `logs` directory. Use these error messages to fix your `ecn.p4` implementation. 3. `ecn.p4` compiles, and the control plane rules are installed, but the switch does not process packets in the desired way. The - `/tmp/p4s..log` files contain trace messages + `logs/sX.log` files contain trace messages describing how each switch processes each packet. The output is detailed and can help pinpoint logic errors in your implementation. The `build/-.pcap` also contains the diff --git a/exercises/link_monitor/README.md b/exercises/link_monitor/README.md index 288e75393..061e890c4 100644 --- a/exercises/link_monitor/README.md +++ b/exercises/link_monitor/README.md @@ -11,7 +11,7 @@ packet such that it is able to pick up the egress link utilization at each hop and deliver it to a host for monitoring purposes. Our probe packet will contain the following three header types: -``` +``` // Top-level probe header, indicates how many hops this probe // packet has traversed so far. header probe_t { @@ -46,7 +46,7 @@ two register arrays: * `byte_cnt_reg` - counts the number of bytes transmitted out of each port since the last probe packet was transmitted out of the port. -* `last_time_reg` - stores the last time that a probe packet was +* `last_time_reg` - stores the last time that a probe packet was transmitted out of each port. Our P4 program will be written for the V1Model architecture implemented @@ -69,7 +69,7 @@ extend this skeleton program to fill out the fields in the probe packet. Before that, let's compile and test the incomplete `link_monitor.p4` -program: +program: 1. In your shell, run: ```bash @@ -95,7 +95,7 @@ path indicated in link-monitor-topo.png. ``` 4. In the other terminal run the `receive.py` script to start receiving and parsing the probe packets. This allows us to monitor -the link utilization within the network. +the link utilization within the network. ```bash ./receive.py ``` diff --git a/exercises/load_balance/README.md b/exercises/load_balance/README.md index 3a2fde0df..c167d6ec1 100644 --- a/exercises/load_balance/README.md +++ b/exercises/load_balance/README.md @@ -1,4 +1,4 @@ -# Load Balancing +# Load Balancing In this exercise, you will implement a form of load balancing based on a simple version of Equal-Cost Multipath Forwarding. The switch you @@ -25,12 +25,12 @@ up a switch in Mininet to test its behavior. 1. In your shell, run: ```bash make - ``` + ``` This will: * compile `load_balance.p4`, and * start a Mininet instance with three switches (`s1`, `s2`, `s3`) configured in a triangle, each connected to one host (`h1`, `h2`, `h3`). - * The hosts are assigned IPs of `10.0.1.1`, `10.0.2.2`, etc. + * The hosts are assigned IPs of `10.0.1.1`, `10.0.2.2`, etc. * We use the IP address 10.0.0.1 to indicate traffic that should be load balanced between `h2` and `h3`. @@ -38,7 +38,7 @@ up a switch in Mininet to test its behavior. for `h1`, `h2` and `h3`, respectively: ```bash mininet> xterm h1 h2 h3 - ``` + ``` 3. Each host includes a small Python-based messaging client and server. In `h2` and `h3`'s XTerms, start the servers: ```bash @@ -113,7 +113,7 @@ fix your `load_balance.p4` implementation. 3. `load_balance.p4` compiles, and the control plane rules are installed, but the switch does not process packets in the desired way. -The `/tmp/p4s..log` files contain trace messages +The `logs/sX.log` files contain trace messages describing how each switch processes each packet. The output is detailed and can help pinpoint logic errors in your implementation. diff --git a/exercises/mri/README.md b/exercises/mri/README.md index 7f1281b47..2118d4304 100644 --- a/exercises/mri/README.md +++ b/exercises/mri/README.md @@ -37,7 +37,7 @@ switch in Mininet to test its behavior. * compile `mri.p4`, and * start a Mininet instance with three switches (`s1`, `s2`, `s3`) configured in a triangle. There are 5 hosts. `h1` and `h11` are connected to `s1`. - `h2` and `h22` are connected to `s2` and `h3` is connected to `s3`. + `h2` and `h22` are connected to `s2` and `h3` is connected to `s3`. * The hosts are assigned IPs of `10.0.1.1`, `10.0.2.2`, etc (`10.0..`). * The control plane programs the P4 tables in each switch based on @@ -128,7 +128,7 @@ store the switch ID and queue depth, and actions that increment the A complete `mri.p4` will contain the following components: 1. Header type definitions for Ethernet (`ethernet_t`), IPv4 (`ipv4_t`), - IP Options (`ipv4_option_t`), MRI (`mri_t`), and Switch (`switch_t`). + IP Options (`ipv4_option_t`), MRI (`mri_t`), and Switch (`switch_t`). 2. Parsers for Ethernet, IPv4, IP Options, MRI, and Switch that will populate `ethernet_t`, `ipv4_t`, `ipv4_option_t`, `mri_t`, and `switch_t`. @@ -136,8 +136,8 @@ populate `ethernet_t`, `ipv4_t`, `ipv4_option_t`, `mri_t`, and 4. An action (called `ipv4_forward`), which will: 1. Set the egress port for the next hop. 2. Update the ethernet destination address with the address of - the next hop. - 3. Update the ethernet source address with the address of the switch. + the next hop. + 3. Update the ethernet source address with the address of the switch. 4. Decrement the TTL. 5. An ingress control that: 1. Defines a table that will read an IPv4 destination address, and @@ -220,7 +220,7 @@ There are several ways that problems might manifest: 3. `mri.p4` compiles, and the control plane rules are installed, but the switch does not process packets in the desired way. The - `/tmp/p4s..log` files contain trace messages + `logs/sX.log` files contain trace messages describing how each switch processes each packet. The output is detailed and can help pinpoint logic errors in your implementation. The `build/-.pcap` also contains the diff --git a/exercises/multicast/README.md b/exercises/multicast/README.md index e8931b102..d2f41626d 100644 --- a/exercises/multicast/README.md +++ b/exercises/multicast/README.md @@ -23,7 +23,7 @@ connects four hosts as follow: h1 h2 \ / \ / - s1 + s1 / \ / \ h3 h4 diff --git a/exercises/qos/README.md b/exercises/qos/README.md index 6cdad6e01..a5ec731a1 100644 --- a/exercises/qos/README.md +++ b/exercises/qos/README.md @@ -78,7 +78,7 @@ missing piece. First we have to change the ipv4_t header by splitting the TOS field into DiffServ and ECN fields. Remember to update the checksum block accordingly. Then, in the egress control block we must compare the -protocol in IP header with IP protocols. Based on the traffic classes +protocol in IP header with IP protocols. Based on the traffic classes and priority, the `diffserv` flag will be set. A complete `qos.p4` will contain the following components: @@ -102,7 +102,7 @@ A complete `qos.p4` will contain the following components: Follow the instructions from Step 1. This time, when your message from `h1` is delivered to `h2`, you should see `tos` values change from 0x1 -to 0xb9 for UDP and 0xb1 for TCP. It depends upon the action you choose +to 0xb9 for UDP and 0xb1 for TCP. It depends upon the action you choose in Ingress processing. To easily track the `tos` values you may want to redirect the output @@ -148,7 +148,7 @@ There are several ways that problems might manifest: implementation. 3. `qos.p4` compiles, and the control plane rules are installed, but the switch does not process packets in the desired way. The - `/tmp/p4s..log` files contain trace messages + `logs/sX.log` files contain trace messages describing how each switch processes each packet. The output is detailed and can help pinpoint logic errors in your implementation. The `build/-.pcap` also contains the diff --git a/exercises/source_routing/README.md b/exercises/source_routing/README.md index 71493f6ea..99c01100f 100644 --- a/exercises/source_routing/README.md +++ b/exercises/source_routing/README.md @@ -60,13 +60,13 @@ bring up a network in Mininet to test its behavior. 5. Type a list of port numbers. say `2 3 2 2 1`. This should send the packet through `h1`, `s1`, `s2`, `s3`, `s1`, `s2`, and `h2`. However, `h2` will not receive the message. - + 6. Type `q` to exit send.py and type `exit` to leave each xterm and the Mininet command line. The message was not received because each switch is programmed with `source_routing.p4`, which drops all packets on arrival. You can -verify this by looking at `/tmp/p4s.s1.log`. Your job is to extend +verify this by looking at `logs/s1.log`. Your job is to extend the P4 code so packets are delivered to their destination. ## Step 2: Implement source routing @@ -84,7 +84,7 @@ A complete `source_routing.p4` will contain the following components: `ethernet` and `srcRoutes` fields. 3. An action to drop a packet, using `mark_to_drop()`. 4. **TODO:** An action (called `srcRoute_nhop`), which will: - 1. Set the egress port for the next hop. + 1. Set the egress port for the next hop. 2. remove the first entry of srcRoutes 5. A control with an `apply` block that: 1. checks the existence of source routes. @@ -123,7 +123,7 @@ There are several ways that problems might manifest: Do you have another instance of mininet running? Did the previous run of mininet crash? if yes, check "Cleaning up Mininet" bellow. 3. `source_routing.p4` compiles but the switch does not process - packets in the desired way. The `/tmp/p4s..log` + packets in the desired way. The `logs/sX.log` files contain trace messages describing how each switch processes each packet. The output is detailed and can help pinpoint logic errors in your implementation. The