fyb/p4tutorials-turkce
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

readme: Update logs path (#448)

Browse Source 
* readme: remove trailing whitespaces

Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>

* readme: update path to log files

Fixes: #447

Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
This commit is contained in:
Radostin Stoyanov 2022-01-19 17:59:20 +00:00 committed by GitHub
parent 1fc826aa43
commit ccc5693807
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 42 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
exercises/basic/README.md
View File

@ -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

22
exercises/basic_tunnel/README.md
View File

@ -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.<switch-name>.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.

6
exercises/ecn/README.md
View File

@ -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.<switch-name>.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/<switch-name>-<interface-name>.pcap` also contains the

8
exercises/link_monitor/README.md
View File

@ -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
```

10
exercises/load_balance/README.md
View File

@ -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.<switch-name>.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.

10
exercises/mri/README.md
View File

@ -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.<Switchid>.<hostID>`).
* 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.<switch-name>.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/<switch-name>-<interface-name>.pcap` also contains the

2
exercises/multicast/README.md
View File

@ -23,7 +23,7 @@ connects four hosts as follow:
h1 h2
\ /
\ /
s1
s1
/ \
/ \
h3 h4

6
exercises/qos/README.md
View File

@ -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.<switch-name>.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/<switch-name>-<interface-name>.pcap` also contains the

8
exercises/source_routing/README.md
View File

@ -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.<switch-name>.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