netsec-ethz / scion-box Goto Github PK

Provide option to setup SIG between SCIONLab nodes

Right now, it will restart if there are pending changes, independently of whether those changes provoked changes in the topology file or not.
E.g. right now due to another bug, update_gen is not modifying the topology file, nor telling the Coordinator to mark the change as processed, and it keeps restarting SCION every time we run update_gen in the attachment points.

We have to decide how to instruct the APs to run a full sync or a (up to now) tradicional delta sync.
We have several options:

• Two timers in AP: one for delta sync, the other for the full one. How do we exclude simultaneous runs?
• One timer, static condition: the script checks a condition (time of day, times since last full sync) and chooses one mode
• Coordinator decides: a condition evaluated in the Coordinator that tells the AP it should run full or delta sync.
• Others?

update_local_gen() inside update_gen.py fails in case the local gen folder and the ASes stored in the SCION coordinator differ. Specifically, request_server throws a missed pk value error for AS configurations that don't exist on the coordinator side. See also netsec-ethz/scion-coord#168

Expected behavior: update_gen.py should ignore ASes from the local gen folder that do not exist in the coordinator and leave them untouched.

The scionlabtesting machine runs four ASes in two ISDs, with one of the ASes in each ISD being a SCIONLab attachment points (APs). I have observed at least two issues with this setup:

• the initial supervisor.conf for the sciond and certificate-server use the default.sock which will clash because both AP-ASes use this; I don't know where the initial configuration is obtained from. Is it from scion-web?
• the port for the internal addresses used by the border routers can clash, as they are based only on the client-AS-number.

Not sure whether this issue should rather be in scion-coord.

Some further issues with running multiple APs on one host are addressed in #42.

Perhaps it is a bit misleading that scionLab.sh and update_gen.py belong to the scion-box repository. Maybe we need another repository called scion-ap with all the code related to SCION attachment points.

There should be an automatic way to download the necessary scripts for an Attachment point and moving them to the correct directories.
This should also set up a cron job or systemd service that automatically executes the scripts.

Send status heartbeats to scion-coord about the status of the box

Basic OpenVPN configuration, SSH Ansible integration (symlinked gen folder, etc.), SCION image setup and scion-coord agent.

sub/util should be updated to the most recent version of the scion-utilities repo.

line[13:-1]

Commented on PR #3 before realizing this has an upstream source:
'This looks dangerous, if the format even only slightly changes, some static predictable string might be used as AS master key.
Since the conf_file is a YAML file, there is no good reason to extract characters from hard-coded indices. Load it as a dict with yaml.load and access the value via its key.'

Are there practical reasons for the current way (line parsing, extracting from fixed offsets)? @mlegner, @jonghoonkwon

This Script will be inside the docker image. It calls the init_box API at the coordinator, receives a list of potential neighbors, runs connection tests and sends back the results by calling the connect_box API.
Afterwards the script receives the gen folder from the coordinator and starts SCION.
Progress: Initial Version is done. But will need to be adjusted to the changed Database.
TODO: Run Connection test server on multiple udp ports to check if enough ports are open for RTT/BW tests aswell as SCION border routers.

We need the prometheus flag to be `-prom "127.0.0.1:blah", but update_gen keeps changing it.
This is needed for the deployment of 2SMS (our monitoring solution).

Right now, it will restart if there are pending changes, independently of whether those changes provoked changes in the topology file or not.
R

Call scion-coord init_box API, run connectivity tests on retrieved AS neightbor information, call connect API

When update_gen can't find the AS in a specified change, it must inform the Coordinator that it couldn't find it. The Coordinator must then do something about this.
Coordinator side issue: netsec-ethz/scion-coord#220

Check format required for the image.
Prepare this binary image to be preinstalled by PCEngines.

Communication from/to Coordinator should follow a protocol. Decide which error codes to use and the semantics of them.
Also decide how to document this (is it a state machine? etc.)

The structure of the update_gen.py should be improved, as suggested by @hausheer.
In particular, the configuration parameters should be moved to a separate file.

Due to an existing limitation in the implementation of the border routers (see scionproto/scion#1981), we cannot have an arbitrary number of interfaces for a single border router. Change the update_gen script to have up to 12 interfaces per border router, and as many border routers as needed to complete the links.
Why 12? Because the BR has 1024 buffers, and each interface will need ~64, and we want to have some slack because of the different traffic patterns: 1024 - (12*2*32) = 256 should be a reasonable headroom.

Modify the update_gen.py script to adjust for the changes introduced in recent PRs on https://github.com/netsec-ethz/scion-coord:
netsec-ethz/scion-coord#133, netsec-ethz/scion-coord#136

As suggested by @hausheer, we need a README file that explains in detail how to set up a new attachment point.
In particular, this should contain detailed information about the configuration of the OpenVPN server.

With the SCIONLab next version we are introducing soon, we can go back to the better performing many interfaces per border router, and remove the changes introduced solving #46 .

• Test that the approach works
• Adapt UTs in test back to use many interfaces

Notify user about status of initial setup via beep
Beep in intervals when connectivity is lost
Notify user about unrecoverable hardware failure via beep

After detecting the network configuration on the main interface, the DHCP server running on the SCIONBox should hand out leases for IPs in the subnet 172.16.0.0/12 on the two remaining interfaces.

Include scion-viz and expose visualization to local clients