Fed4FIRE VLAN Stitching

It is possible to connect Grid'5000 resources to resources from other testbeds part of Fed4FIRE or GENI. This is implemented by stitching (bridging together) global KaVLAN vlans to VLANs connected to the imec SDX.

Global picture

This is slide 16 from this presentation.

Grid'5000 is connected to the Iminds SDX (now imec SDX), hosted in Ghent (Belgium). That SDX is also connected to other SDXes, which means that you should be able to connect your Grid'5000 nodes to e.g. Cloudlab nodes. This is implemented using a stitcher service.

Step by step process

On the Fed4FIRE side

• Get Fed4FIRE credentials. You can request an account as part of the grid5000 project.
• Use the jFed tool (Fed4FIRE's client) to reserve resources on Fed4FIRE.
• Include a Dedicated Ext. Network Connection, and choose one of the Grid'5000 VLANs (1290-1294).
• Start your experiment

On the Grid'5000 side

• Reserve nodes, and a global KaVLAN. Deploy your nodes. For example:

oarsub -t deploy -l "{type='kavlan-global'}/vlan=1+nodes=1,walltime=0:30" -I
kavlan -V # => 15
kadeploy3 -e debian9-x64-min -f $OAR_NODEFILE -k --vlan 15

Stitching the global KaVLAN with the SDX VLAN

You need to interact using the stitcher service API. Example commands are:

• List all stitchings:

curl  https://api.grid5000.fr/3.0/stitcher/stitchings

• Add a stitching between KaVLAN VLAN 14, and SDX VLAN 1291:

curl -d '{"id":"14", "sdx_vlan_id":"1291"}' -H "Content-Type: application/json" -X POST https://api.grid5000.fr/3.0/stitcher/stitchings

• Remove the stitching for KaVLAN VLAN 14: (this is also done automatically at the end of the resource reservation)

curl -X DELETE https://api.grid5000.fr/3.0/stitcher/stitchings/14

• For debugging purposes, the stitcher's network configuration is visible with:

curl https://api.grid5000.fr/3.0/stitcher/network_configuration

Notes

Several KaVLAN VLANs connected to the same SDX VLAN

There is nothing in the current implementation that prevents connecting several KaVLAN VLANs to the same SDX VLAN. If you do that, please not that you will create a single L2 network spanning several KaVLAN VLANs. As a result the DHCP servers from each VLAN will each answer requests from nodes, which can result in nodes not having the IP address you expect (for example, you set grisou-1 to VLAN 14, but since VLAN 14 and 16 are the same L2 network, grisou-1 will get the IP address for grisou-1-kavlan-16).

This issue can be avoided by only activating the stitching after the initial DHCP exchanges, and/or by doing your own IP allocation without relying on the DHCP servers provided by KaVLAN.