Verifying SCION installation¶
After running your SCION infrastructure, it is necessary to verify that it is working correctly.
There are several methods of doing this. Some of them are described in this post.
The recommended way of verifying a correct SCION infrastructure deployment is running the visualization tool SCIONLab Apps Web Visualization. This user-friendly tool will display paths from your AS to different destinations, verifying the correct function of the control plane.
Another approach is to directly verify AS services using the terminal. You will have to log into the machine hosting the SCION services either (with
vagrant ssh if it is a virtual machine). If your AS is correctly configured and functioning as expected, the following checks would all pass. You can therefore choose which ones from them to check.
Inspecting log files¶
The SCION log files can be accessed with the following command:
tail -f $SC/logs/bs*.DEBUG
In particular, the beacon server log file should contain lines like
[DEBUG] (MainThread) Successfully verified PCB ca8e78c198ca
If you don't find any line mentioning the successful verification of PCBs, your AS probably has issues. Please refer to the troubleshooting section.
If you are running the SCION virtual machine image, you can check the same by running:
from any directory
Run pingpong client¶
If your AS is working as expected, you should be able to use a simple data plane application that is delivered with the SCION binaries that sends a small request (ping) and waits for its response (pong). We run the
pingpong servers in each of the four official attachment points:
You can run the
pingpong client against any of those servers in the list above. For example, if your AS ID was
17-ffaa:1:1 and you wanted to verify
pingpong against the attachment point in the ISD 18, you would run:
cd $SC ./bin/pingpong -local 17-ffaa:1:1,[127.0.0.1]:0 -remote 18-ffaa:0:1202,[18.104.22.168]:40002 Using path: Hops: [17-ffaa:1:1 1>147 17-ffaa:0:1107 1>4 17-ffaa:0:1102 3>3 17-ffaa:0:1103 4>8 17-ffaa:0:1101 5>4 18-ffaa:0:1201 6>1 18-ffaa:0:1202] Mtu: 1472 Received 13 bytes from 18-ffaa:0:1202,[22.214.171.124]:40002: seq=0 RTT=156.675ms Received 13 bytes from 18-ffaa:0:1202,[126.96.36.199]:40002: seq=1 RTT=157.699ms ...
If you're running the application on a local topology, make sure to specify the correct socket using the
-sciond flag, e.g. by adding
-sciond /run/shm/sciond/sd1-ff00_0_110.sock. You can find the corresponding socket in the
sciond.toml file of the endhost inside the
Passing this test is a condition sufficient to say that your AS works as expected. If it fails, please refer to the troubleshooting section.
If while trying to run
pingpong you receive an error such as:
squic: Unable to load TLS cert/key > open gen-certs/tls.pem: no such file or directory
Just run the following:
cd $SC old=$(umask) mkdir -p "gen-certs" umask 0177 openssl genrsa -out "gen-certs/tls.key" 2048 umask "$old" openssl req -new -x509 -key "gen-certs/tls.key" -out "gen-certs/tls.pem" -days 3650 -subj /CN=scion_def_srv
This would have generated the missing
key files. Run again
pingpong and you should not see the error about the missing certificate.