|
|
# Debugging and Troubleshooting
|
|
|
|
|
|
### Monitoring Traffic
|
|
|
## Monitoring Traffic
|
|
|
|
|
|
Sniffing traffic can be a very powerful tool when debugging your P4 program. Basic things like verifying
|
|
|
if traffic crosses certain path, or if header fields look like expected can be easily achieved by just
|
|
|
observing traffic. For that, there is a wide range of tools that can be used:
|
|
|
|
|
|
#### Pcap Files:
|
|
|
### Pcap Files:
|
|
|
|
|
|
The `simple_switch` provides an option to save all the traffic that crosses its interfaces in a pcap file. To
|
|
|
enable pcap logging when starting your switch, use the `--pcap=<output_dir>` command line option. For Example:
|
... | ... | @@ -21,7 +19,7 @@ Pcap logging will create several files using the following naming: `<sw_name>-<i |
|
|
|
|
|
If you enable pcap in the `p4app.json` configuration file, switches will be started with the `--pcap` option and use as output dir `./pcap`.
|
|
|
|
|
|
#### Wireshark/Tshark:
|
|
|
### Wireshark/Tshark:
|
|
|
|
|
|
Another option is to observe the traffic as it flows. For that you can use tools like `tshark` and its GUI version `wireshark`. Wireshark
|
|
|
is already installed in the VM, you can find its executable in the desktop.
|
... | ... | @@ -32,7 +30,7 @@ To capture traffic with tshark run: |
|
|
sudo tshark -i <interface_name>
|
|
|
```
|
|
|
|
|
|
#### Tcpdump:
|
|
|
### Tcpdump:
|
|
|
|
|
|
Similarly, and if you prefer, you can use `tcpdump` (also already installed in the VM).
|
|
|
|
... | ... | @@ -42,11 +40,11 @@ To capture traffic with tcpdump run (shows link-layer information and does not r |
|
|
sudo tcpdump -l -enn -i <interface_name>
|
|
|
```
|
|
|
|
|
|
### Logging
|
|
|
## Logging
|
|
|
|
|
|
To enable logging, make sure that you enabled `--with-nanomsg` flag to `configure` before compiling `bmv2`.
|
|
|
|
|
|
#### Console logging
|
|
|
### Console logging
|
|
|
|
|
|
To enable console logging when starting your switch, use the `--log-console` command line option. For example:
|
|
|
|
... | ... | @@ -61,17 +59,17 @@ it to a log file: |
|
|
sudo simple_switch -i 0@<iface0> -i 1@<iface1> --log-console <path to JSON file> >/path_to_file/sw.log
|
|
|
```
|
|
|
|
|
|
#### P4 Utils Integration
|
|
|
### P4 Utils Integration
|
|
|
|
|
|
If you enable logging in the `p4app.json` configuration file, switches will automatically write all the console logging
|
|
|
into a file in the `./log` directory and with `<sw_name>.log`.
|
|
|
|
|
|
#### CLI logging
|
|
|
### CLI logging
|
|
|
|
|
|
If logging is enabled, and you use the `simple_switch_CLI` when starting the topology (with `p4utils`) the output
|
|
|
of the `cli` will be also logged in the log folder under the name `<sw_name>_cli_output.log`
|
|
|
|
|
|
#### Event logging
|
|
|
### Event logging
|
|
|
|
|
|
To enable event logging when starting your switch, use the *--nanolog* command
|
|
|
line option. For example, to use the ipc address *ipc:///tmp/bm-log.ipc*:
|
... | ... | @@ -94,7 +92,7 @@ to check the `print` messages displayed by `p4run`. Try to find a line that look |
|
|
s1 -> Thrift port: 9090
|
|
|
```
|
|
|
|
|
|
### Debugger
|
|
|
## Debugger
|
|
|
|
|
|
To enable the debugger, make sure that you passed the `--enable-debugger` flag
|
|
|
to `configure`. You will also need to use the `--debugger` command line flag
|
... | ... | @@ -108,7 +106,7 @@ attach the debugger to the switch: |
|
|
You can find a P4 debugger user guide in the bmv2
|
|
|
[docs](https://github.com/p4lang/behavioral-model/blob/master/docs/p4dbg_user_guide.md).
|
|
|
|
|
|
### Attaching Information to a Packet
|
|
|
## Attaching Information to a Packet
|
|
|
|
|
|
Some times you do not want to use the logging system or debugger, or basically they are disabled. Yet, you could still
|
|
|
get some insights on what the code does by just modifying a header field depending on which part of the code
|
... | ... | @@ -116,14 +114,14 @@ gets executed and check that value when the packet leaves the switch. Of course |
|
|
and use several fields, read the value of a register and save it in the header, and so on.
|
|
|
|
|
|
|
|
|
### Using P4 tables to inspect headers/metadata values
|
|
|
## Using P4 tables to inspect headers/metadata values
|
|
|
|
|
|
We already have an [example](../examples/debugging_table/README.md) covering this. Basically the idea is to use
|
|
|
P4 tables and do an `exact` match to all the fields you want to track. Every time the table is executed, if the bmv2
|
|
|
debugging is enabled, the switch will write the values of each field that was used to match the table entry in the switch
|
|
|
log file. See the example for more information.
|
|
|
|
|
|
### If the above did not solve your problem:
|
|
|
## If the above did not solve your problem:
|
|
|
|
|
|
P4, and all the tools around are quite new. Several times things just do not work
|
|
|
because there is a bug in the compiler or in the software switch implementation.
|
... | ... | |