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

Fix links in markdown files

Browse Source
This commit is contained in:
Antonin Bas
2017-06-01 11:29:02 -07:00
parent 6b546481a5
commit 30ecf6fc07
10 changed files with 68 additions and 70 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
examples/TLV_parsing/README.md
View File

@@ -48,9 +48,9 @@ So in a nutshell, all this P4 program does is:
We provide a small demo to let you test the program. It consists of the
following scripts:
- [run_switch.sh] (run_switch.sh): compile the P4 program and starts the switch,
- [run_switch.sh](run_switch.sh): compile the P4 program and starts the switch,
also configures the data plane by running the CLI [commands] (commands.txt).
- [send_one.py] (send_one.py): send an IPv4 packet with options
- [send_one.py](send_one.py): send an IPv4 packet with options
To run the demo:
- start the switch and configure the tables: `sudo ./run_switch.sh`.

2
examples/action_profile/README.md
View File

@@ -12,7 +12,7 @@ between P4 tables is not supported in bmv2.
As always, you can start the switch with `./run_switch.sh` (and wait until
`READY` is displayed). We program the dataplane with the following CLI commands
(from [commands.txt] (commands.txt)):
(from [commands.txt](commands.txt)):
```
01. table_indirect_create_group ecmp_group

14
examples/axon/README.md
View File

@@ -69,13 +69,13 @@ entries.
We provide a small demo to let you test the program. It consists of the
following scripts:
- [run_demo.sh] (run_demo.sh): compiles the P4 program, starts the switch,
configures the data plane by running the CLI [commands]
(commands.txt), and starts the mininet console.
- [receive.py] (receive.py): listens for Axon formatted packets. This
command is intended to be run by a mininet host.
- [send.py] (send.py): sends Axon formatted packets from one host to
another. This command is intended to be run by a mininet host.
- [run_demo.sh](run_demo.sh): compiles the P4 program, starts the switch,
configures the data plane by running the CLI [commands](commands.txt), and
starts the mininet console.
- [receive.py](receive.py): listens for Axon formatted packets. This command is
intended to be run by a mininet host.
- [send.py](send.py): sends Axon formatted packets from one host to another.
This command is intended to be run by a mininet host.
To run the demo:
./run_demo.sh will compile your code and create the Mininet network described

14
examples/copy_to_cpu/README.md
View File

@@ -13,7 +13,7 @@ The P4 program does the following:
to `0xab`)
- the original packet is dropped in the egress pipeline
Take a look at the [P4 code] (p4src/copy_to_cpu.p4). The program is very short
Take a look at the [P4 code](p4src/copy_to_cpu.p4). The program is very short
and should be easy to understand. You will notice that we use a mirror session
id of `250` in the program. This number is not relevant in itself, but needs to
be consistent between the P4 program and the runtime application.
@@ -22,16 +22,16 @@ be consistent between the P4 program and the runtime application.
We provide a small demo to let you test the program. It consists of the
following scripts:
- [run_switch.sh] (run_switch.sh): compile the P4 program and starts the switch,
also configures the data plane by running the CLI [commands] (commands.txt)
- [receive.py] (receive.py): sniff packets on port 3 (veth7) and print a hexdump
- [run_switch.sh](run_switch.sh): compile the P4 program and starts the switch,
also configures the data plane by running the CLI [commands](commands.txt)
- [receive.py](receive.py): sniff packets on port 3 (veth7) and print a hexdump
of them
- [send_one.py] (send_one.py): send one simple IPv4 packet on port 0 (veth1)
- [send_one.py](send_one.py): send one simple IPv4 packet on port 0 (veth1)
If you take a look at [commands.txt] (commands.txt), you'll notice the following
If you take a look at [commands.txt](commands.txt), you'll notice the following
command: `mirroring_add 250 3`. This means that all the cloned packets with
mirror id `250` will be sent to port `3`, which is our de facto *CPU port*. This
is the reason why [receive.py] (receive.py) listens for incoming packets on port
is the reason why [receive.py](receive.py) listens for incoming packets on port
`3`.
To run the demo:

21
examples/meter/README.md
View File

@@ -3,8 +3,8 @@
## Description
This program illustrates as simply as possible how to use meters in P4 with
bmv2. bmv2 uses two-rate three-color meters as described [here]
(https://tools.ietf.org/html/rfc2698).
bmv2. bmv2 uses two-rate three-color meters as described
[here](https://tools.ietf.org/html/rfc2698).
For each incoming packet the `m_table` table is applied and the appropriate
meter (based on the packet's source MAC address) is executed. Based on the
@@ -17,16 +17,15 @@ to port 2 of the switch.
After that, the packet will go through a second table, `m_filter`, which can
either be a no-op or drop the packet based on how the packet was tagged by the
meter. If you take a look at the [runtime commands] (commands.txt) we wrote for
meter. If you take a look at the [runtime commands](commands.txt) we wrote for
this example, you will see that we configure the table to drop all the packets
for which the color is not *GREEN* (i.e. all packets for which `meta.meter_tag`
is not `0`).
The [commands.txt] (commands.txt) file also gives you the meter
configuration. In this case, the first rate is 0.5 packets per second, with a
burst size of 1, and the second rate is 10 packets per second, with a burst size
of 1 also. Feel free to play with the numbers, but these play nicely with the
demonstration below.
The [commands.txt](commands.txt) file also gives you the meter configuration. In
this case, the first rate is 0.5 packets per second, with a burst size of 1, and
the second rate is 10 packets per second, with a burst size of 1 also. Feel free
to play with the numbers, but these play nicely with the demonstration below.
Note that we use an `indirect` meter array, because `direct` ones are not
supported yet by bmv2.
@@ -35,9 +34,9 @@ supported yet by bmv2.
We provide a small demo to let you test the program. It consists of the
following scripts:
- [run_switch.sh] (run_switch.sh): compile the P4 program and starts the switch,
also configures the data plane by running the CLI [commands] (commands.txt).
- [send_and_receive.py] (send_and_receive.py): send packets periodically on port
- [run_switch.sh](run_switch.sh): compile the P4 program and starts the switch,
also configures the data plane by running the CLI [commands](commands.txt).
- [send_and_receive.py](send_and_receive.py): send packets periodically on port
0 and listen for packets on port 2.
To run the demo:

8
examples/resubmit/README.md
View File

@@ -8,7 +8,7 @@ pipeline. For more information, please refer to the P4 specification.
The P4 program only consists of an ingress pipeline, with 2 tables:
`t_ingress_1` and `t_ingress_2`. When a packet enters the pipeline, the
following happens (based on the P4 program and the [commands.txt] (commands.txt)
following happens (based on the P4 program and the [commands.txt](commands.txt)
files):
- the packet hits `table_ingress_1` and the egress port is set to 2.
- the packet hits `table_ingress_2`, `mymeta.f1` is set to 1 and the
@@ -22,7 +22,7 @@ files):
We provide a small demo to let you test the program. It consists of the
following scripts, which you need to run one after the other, in 2 separate
terminals:
- [run_switch.sh] (run_switch.sh): compile the P4 program and starts the switch,
also configures the data plane by running the CLI [commands] (commands.txt).
- [send_and_receive.py] (send_and_receive.py): send a packet on port 0 (veth1),
- [run_switch.sh](run_switch.sh): compile the P4 program and starts the switch,
also configures the data plane by running the CLI [commands](commands.txt).
- [send_and_receive.py](send_and_receive.py): send a packet on port 0 (veth1),
wait for the forwarded packet on port 3 (veth7).

6
examples/simple_nat/README.md
View File

@@ -3,8 +3,8 @@
## Description
This program implements a very basic full-cone NAT for TCP traffic (over
IPv4). According to [Wikipedia]
(https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation),
IPv4). According to
[Wikipedia](https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation),
a full-cone NAT is defined as follows:
Once an internal address (iAddr:iPort) is mapped to an external address
@@ -43,7 +43,7 @@ the packet is forwarded appropriately.
The most important part of the program is the `nat` table. If you understand
what this table is doing, the rest of the program is mostly IPv4 forwarding. You
should also take a long look at [nat_app.py] (nat_app.py), which manages the
should also take a long look at [nat_app.py](nat_app.py), which manages the
mappings and dynamically adds rules to the `nat` table.
We use 11 as the CPU port. There is a special CPU veth pair (`cpu-veth-0` /