CERN Accelerating science

HEPiX IPv6 distributed testbed

This page documents the plans and status of the HEPiX IPv6 distributed testbed.

List of availble nodes

HEPiX IPv6 sites perfSONAR dashboard

Testbed node installation requirements

  • Architecture: x86_64 (for full support of ‘WLCG’ applications and middleware)
  • Operating System: Scientific Linux 5 (for the same reason)
  • At least 1 Gb/s network interface (and corresponding bandwith to the border gateway)
  • Host X509 certificate and key containing the name that is resolved as both IPv4 and IPv6 addresses installed in /etc/grid-security/host{cert|key}.pem (Here some help on making the certificates).
  • NTPd daemon running and aligned to GPS within a few hops.
  • Active network services:
    • gridftp - Installation notes for a standalone server can be found here
    • open incoming TCP port 2811 in the firewall for the gridftp server
  • Access configuration (gridmap file or equivalent):
    • Allow the ‘ipv6.hepix.org’ VO, hosted on voms2.cnaf.infn.it (backup server on voms-02.pd.infn.it). A simple GSI authorization module, mapping this VO on user ‘ipv6user’ can be downloaded in RPM form here.

List of currently configured testbed nodes

A perl script to validate the existence and configuration of nodes listed in the table on the old twiki page can be downloaded here: http://www.mi.infn.it/ipv6/ipv6_site_test.pl
It depends only on LWP::UserAgent but requires working host, ping and ping6 commands in the current PATH.
Note: The testbed host entry has to be added to this table before running the script.

The full mesh of tests for IPv4 and IPv6 globus-url-copy based gridFTP transfers is available at http://ui2-4.dir.garr.it/globus-url-copy-ipv6 and http://hermes-gva.uslhcnet.org/globus-url-copy-ipv6 .
The two corresponding bash scripts used to generate it are available from http://ui2-4.dir.garr.it/REPO/IPv6/.

List of availble nodes

Configuring a Dual Stack VM at CERN

In the CERN Agile Infrastructure it is possible to ask for a Virtual Machine and set it up as dual stack node. This allows procuring "hardware" for testing of any kind of service on dual stack. To setup a dual stack node, follow those instructions. 

Each CERN machine is by default assigned an IPv6 alias (beside the IPv4 hostname), resolved only by the IPv6 DNS. For a dual stack service this is useful for testing specifically one of the two network protocols. The IPv6 hostname can be obtained from the IPv4 replacing ".cern.ch" with ".ipv6.cern.ch". For example, for the host scipv6.cern.ch you have: 

$ ping scipv6.cern.ch
PING scipv6.cern.ch (188.184.21.161): 56 data bytes
64 bytes from 188.184.21.161: icmp_seq=0 ttl=60 time=10.408 ms

$ ping scipv6.ipv6.cern.ch
ping: cannot resolve scipv6.ipv6.cern.ch: Unknown host

$ ping6  scipv6.ipv6.cern.ch
PING6(56=40+8+8 bytes) 2001:1458:202:9a::101:6f60 --> 2001:1458:201:14::100:5c4
16 bytes from 2001:1458:201:14::100:5c4, icmp_seq=0 hlim=60 time=98.909 ms

$ ping  scipv6.ipv6.cern.ch
ping: cannot resolve scipv6.ipv6.cern.ch: Unknown host

 

  

Statistics

Test of additional services

FTS

Installation notes for a standalone FTS/FTA server (available at endpoint https://seipersei.mi.infn.it:8443/glite-data-transfer-fts/services/FileTransfer) can be found here. Open issues:

  1. Had to base test on glite 3.2 repository, as many configuration scripts still don’t match the EMI-1 installation.
  2. cGSI-GSOAP does not resolve IPv6 names up to version ‘CGSI_gSOAP_2.7-1.3.3-1’, still found on some production UIs. Gsoap supports IPv6 on TCP since version 2.5 (2005), and on UDP since version 2.7.2 (still 2005), but it was apparently compiled in without the WITH_IPv6 flag.
  3. As of April 17, 2012 the FTS Oracle back-end is hosted on an IPv6-accessible node at CERN. Note: Oracle claims IPv6 compatibility from version 11g release 2, but FTS transfer agent libraries in EMI-1 still carry a hard dependency on libclntsh.so.10.1, libnnz10.so, libocci.so.10.1. Transfer agent library carrying a dependency on both v10 and v11 client versions appeared with EMI-1 Update 13 on February 17, 2012. We rebuilt these by hand for the time being.
  4. BTW: Any takers for more extensive dual-stack tests of the Oracle client/server communication via JDBC, sqlplus, libocci?
  5. Transfer agents (and in general Tomcat/Axis servlets) can be invoked on dual stack hosts and from dual stack clients, but the ‘urlcopy’ agent still uses IPv4 for file transfer. This is because, exactly as in the globus-url-copy command, IPv6 resolution in the Globus FTP client needs to be explicitely enabled. This is still not true in the SVN head of the transfer-url-copy component. A patch needed to be applied as described in the install notes.
  6. Main conclusions:
    1. FTS services on IPv4 don’t break on dual-stack hosts.
    2. Only what is used in production can be tested effectively (but we may be missing recent developments, and need to validate any conclusion on the development versions of affected components.
    3. Commercial dependencies do dictate their timelines and deployment options and may require large scale upgrades (and related testing).
    4. Functional IPv6 support in a software component does not imply that IPv6 transport is enabled by default. This is hard to capture in either a survey or by automated code-checking tools.
    5. Installation and configuration complexity of standalone components outweigh the extra trouble of pointing to individual components in an integrated service host.