Fed4FIRE VLAN Stitching: Difference between revisions

From Grid5000
Jump to navigation Jump to search
No edit summary
No edit summary
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Portal|User}}
{{Portal|User}}


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.
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 [https://www.geant.org/Services/Connectivity_and_network/GTS GEANT Testbeds service (GTS)], and that are managed using the same procedure.
 
{{Warning|text=This service is experimental. If you need support, please contact the Grid'5000 Technical Team (see [[Support]])}}


= Global picture =
= Global picture =
Line 7: Line 11:
This is slide 16 from [https://fed4fire.eu/wp-content/uploads/sites/10/2018/08/porto5g_fed4fire_imec.pdf this presentation].
This is slide 16 from [https://fed4fire.eu/wp-content/uploads/sites/10/2018/08/porto5g_fed4fire_imec.pdf 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.
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 =
= Step by step process =
Line 19: Line 24:
  oarsub -t deploy -l "{type='kavlan-global'}/vlan=1+nodes=1,walltime=0:30" -I
  oarsub -t deploy -l "{type='kavlan-global'}/vlan=1+nodes=1,walltime=0:30" -I
  kavlan -V # => 15
  kavlan -V # => 15
  kadeploy3 -e debian9-x64-min -f $OAR_NODEFILE -k --vlan 15
  kadeploy3 -e debian10-x64-min -f $OAR_NODEFILE -k --vlan 15


== Stitching the global KaVLAN with the SDX VLAN ==
== Stitching the global KaVLAN with the SDX VLAN ==
Line 27: Line 32:
* Add a stitching between KaVLAN VLAN 14, and SDX VLAN 1291:  
* Add a stitching between KaVLAN VLAN 14, and SDX VLAN 1291:  
  <code class="command">curl</code> -d '{"id":"<code class="replace">14</code>", "sdx_vlan_id":"<code class="replace">1291</code>"}' -H "Content-Type: application/json" -X POST https://api.grid5000.fr/3.0/stitcher/stitchings
  <code class="command">curl</code> -d '{"id":"<code class="replace">14</code>", "sdx_vlan_id":"<code class="replace">1291</code>"}' -H "Content-Type: application/json" -X POST https://api.grid5000.fr/3.0/stitcher/stitchings
* Remove the stitching for KaVLAN VLAN 14:
* Remove the stitching for KaVLAN VLAN 14: (this is also done automatically at the end of the resource reservation)
  <code class="command">curl</code> -X DELETE https://api.grid5000.fr/3.0/stitcher/stitchings/<code class="replace">14</code>
  <code class="command">curl</code> -X DELETE https://api.grid5000.fr/3.0/stitcher/stitchings/<code class="replace">14</code>
* For debugging purposes, the stitcher's network configuration is visible with:
* For debugging purposes, the stitcher's network configuration is visible with:
Line 34: Line 39:
= Notes =
= Notes =
== Several KaVLAN VLANs connected to the same SDX VLAN ==
== 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).
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.
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.

Revision as of 09:20, 21 April 2020


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.png Warning

This service is experimental. If you need support, please contact the Grid'5000 Technical Team (see Support)

Global picture

SDX Topology.png

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

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 debian10-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 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.