Fed4FIRE VLAN Stitching
|
Note |
|---|---|
This page is actively maintained by the Grid'5000 team. If you encounter problems, please report them (see the Support page). Additionally, as it is a wiki page, you are free to make minor corrections yourself if needed. If you would like to suggest a more fundamental change, please contact the Grid'5000 team. | |
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 Software Defined Exchange (SDX).
Additionally, There are also 5 VLANs (1390 to 1394) that connect Grid'5000 to GEANT Testbeds service (GTS), and that are managed using the same procedure.
|
Warning |
|---|---|
This service is experimental. If you need support, please contact the Grid'5000 Technical Team (see Support) | |
Overview
- Grid'5000 is part of the European testbed federation Fed4FIRE. As such services have been setup to link the Grid'5000 vlans to vlans in other testbeds using software defined networks (SDX).
- Through stitching users can link Grid'5000 global vlans to to external vlans linked to other testbeds.
- This allows for the creation of wide area layer2 networks involving nodes from Grid'5000 and partner testbeds.
- Our partner testbeds to which we can link are IMEC VirtualWall (1&2) and GEANT Testbed Services.
- External vlans 1290 to 1294 link to IMEC.
- External vlans 1390 to 1394 link to GTS.
This page describes how to stitch a Grid'5000 global vlan to an external vlan using the Grid'5000 native API. Fed4FIRE users using jFed should look to the Fed4FIRE page for instruction on how to stitch network in jFed-Experimenter.
Global picture
This is slide 16 from this presentation.
Grid'5000 is connected to the Iminds SDX (now imec SDX), hosted in Ghent (Belgium). This is implemented using a stitcher service. 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 (however note that this service is very experimental: while the connection to IMEC and Virtual Wall testbeds work, the state of other interconnections might vary over time).
Step by step process
|
|
Warning |
|---|---|
As of November 2020 Fed4FIRE VLAN Stitching should be available directly in jFed-Experimenter. See the Fed4FIRE FAQ page. The process described on this page explains how to do it manually. | |
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 debian11-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. See here for the stitching API specification.
Example commands are:
- List all stitchings:
curl https://api.grid5000.fr/stable/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/stable/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/stable/stitcher/stitchings/14
- For debugging purposes, the stitcher's network configuration is visible with:
curl https://api.grid5000.fr/stable/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 note 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.