240 likes | 242 Views
EGI IPv6 Report for EGI NetSup F2F @ EGI TF 2012. Mario Reale GARR mario.reale@garr.it. September 18, 2012 EGI TF 2012 Prague. 1. Outline. EGI goals w.r.t. IPv6 Current stand of Testbed Infrastructure Preliminary Testing Results Plans for next weeks/months. 2.
E N D
EGI IPv6Report for EGI NetSup F2F @ EGI TF 2012 Mario Reale GARR mario.reale@garr.it September 18, 2012 EGI TF 2012 Prague 1
Outline • EGI goals w.r.t. IPv6 • Current stand of Testbed Infrastructure • Preliminary Testing Results • Plans for next weeks/months 2
Goals for EGI w.r.t. IPv6 • Obviously, IPv4-only nodes cannot talk to IPv6-only nodes without protocol translation at some level • Wherever possible, Dual Stack should be pursued • So far, protocol translation mechanisms have not been taken into consideration • No solution provided for the integration of IPv6-only resources in an IPv4 Grid • Therefore our goals so far are: • 1. Ensure switching on IPv6 does not break functionality provided using IPv4 in a Dual Stack approach (IPv4 to IPv4 in the presence of also the IPv6 stack) • 2. Demonstrate we can use the Grid using IPv6 using EMI/UMD middleware • IPv6-only grid clients can connect to IPv6-only grid servers • The same grid middleware could then be used in an IPv4 environment and in an IPv6 environment
Goals translated in practice • An applicable approach today is having a unique grid middleware (including all required external dependencies) enabling IPvX Grid nodes to connect to IPvX Grid nodes and vice versa ( where X = 4 or 6) • Additionally, we should understand exactly what happens in a Dual Stack approach • What protocol is used/preferred ? • Does IPv6 break IPv4-provided functionality ? • Can it be configured ?
Goals translated in practice • Assess the overall IPv6 status w.r.t. IPv6 compliance of • The grid middleware • The required operational services and tools • Report all sources of problems to EGI and Technology providers • I.e. measure how far are we from IPv6-compliant middleware • For all EGI-related middleware families ( Globus IGE, ARC, gLite, UNICORE, dCache) • UMD released components • Check/ Verify that switching on IPv6 does not break IPv4 provided functionality • This is however less than half of our goals: we still need IPv4 addresses/nodes • Test EMI / UMD middleware components and verify that • They can be deployed ( installed and configured OK ) • They work using IPv4-only, IPv6-only and Dual Stack
IPv6-only resources • Integrate IPv4-only resources and IPv6-only resources in a unique functional pool ? Not really. • Including IPv6-only resources in the EGI Grid (mostly IPv4) would imply protocol translation • To merge IPv6 and IPv4 resources, there are IPv4 / IPv6 translation mechanisms available and possible gateway approaches, but the majority of them • Introduce an overhead w.r.t. grid functionality to be provided • Often represent a single point of failure in a Grid distributed architecture • Do not scale easily • Realistically achievable (at least to start with) is to be able to have a network-agnostic middleware, external dependencies and operational tools enabling us to implement an IPv4-infrastructure and an IPv6-infrastructure Being able to provide 2 separate Grid pillars / resource-sets • Functional IPv4-IPv6 integration out of our scope so far • However, we should not be far at all from an IPv6-compliant middleware • however no one has certified what is being provided w.r.t. IPv6 compliance • various spreads problems are likely to be there
Down-to-earth strategy • EGI strategy for assessing IPv6 compliance very down-to-earth • We plan to produce • Detailed Test reports where CLI commands are tested in 4 network config for Client and Server • A Summary Matrix reporting “OK”, or “Not working” for 4 network configurations: • A) Client and Server both in Dual Stack • B) Client in IPv6-only, Server in Dual Stack • C) Server in IPv6-only. Client in Dual Stack • D) Client and Server both in IPv6-only • An overall initial IPv6 assessment table for services summarizing also possible issues related to installation, configuration, smoke tests, basic functional tests, for each Grid service
Goals of EGI IPv6 testbed • Allow general purpose testing of UMD components using the IPv6 protocol • Enable specific IPv6 test campaigns on selected UMD components or required external dependencies • Provide an hands-on IPv6 testbed for possible IPv6 tutorials for the EGI site administrators community, both on IPv6 in general and IPv6 Security • Enable IPv6 testing of specific applications relevant to the EGI UCB / User Community • Allow the IPv6 testing of EGI-Inspire JRA1 Operational Tools components • Provide support and exploit synergies for the EGI Federated Clouds task force w.r.t. IPv6 ( to be defined, just started) • Complement the work done by the HEPiX IPv6 WG, focusing on the middleware
IPv6 Testbed Resources • Many new Grid services installed at GARR, ARNES, FZU, GRNET • Overall, ~ 15 servers deploying ARC and gLite services
Current Strategy • We decided to start focusing on Site Computing and InfoSys resources • To be complementary to HEPiX • First full cycles of installation / configuration / smoke testing will be reported by single test reports • Detailed test reports being produced: ARC CE, CREAM CE, DPM-SE • Wiki based reporting and documenting : Refer to https://wiki.egi.eu/wiki/IPv6 Test reports on https://wiki.egi.eu/wiki/IPv6TestReports
Already identified issues • Certification Authorities related files are not reachable ( CA-files, CRLs..) • How do I set up the Grid nodes and the User/Sites/Grid Security Infrastructure ? • Some external dependencies are not IPv6 compliant or compiled without the required options • We do not have a 100 % clear picture of what should be the expected degree of IPv6 compliance of all UMD middleware families and components • Would help guiding us to verify things • Sites are a bit reluctant to enable IPv6 (if not really needed) given lower level of security control / LAN protection expertise
How we decided to report • Global IPv6 assessment table including installation, configuration, smoke test for each services – includes logs/references • Specific Client/Server summary table for 4 Network Configuration • Detailed Test Teports for each service : log of command outcomes (in the 4 configurations) https://wiki.egi.eu/wiki/IPv6TestReports
Client/Server IPvX stack:Test Categories • A) Dual Stack on Client and Server • B) IPv6-only Client; Dual Stack Server • C) IPv6-only Server, Dual Stack Client • D) IPv6-only on both Client and Server
CREAM CE test • Torque CREAM CE installed and configured • IPv6-only installation OK • Test to be finalized • IPv6-only client : OK • Issues with Torque : job stuck in the queue • Preliminary outcome on https://wiki.egi.eu/wiki/IPv6TestReportGliteCreamCE
DPM SE test • DPM-SE installed at GARR • IPv6-only installation to be tested still • Basic tests for some initial functionality carried out • Upgraded MySQL : 5.1 5.5 • Tests be finalized • Preliminary results on https://wiki.egi.eu/wiki/IPv6TestReportGliteDPM
ARC • ARC CE tests : see Barbara’s talk
Uncovered • UNICORE tests started but poor feedback received • dCache – just basic contacts • IGE Globus – just basic contacts
Next steps • Complete tests of CREAM CE, DPM SE • Torque/MAUI requires digging into the issue • Identify responsible NGIs/Teams for UNICORE, IGE Globus and d-Cache • Start collaboration with EGI-Inspire JRA1 on operations tools • Pursue functional integration of testbed services with EMI and HEPiX • Provide support information for sites to deploy site BDII / site EMIR
Towards a global IPv6 testbed ? • Required steps to build a global, extended, cross-initiative IPv6 testbed have been carried out • Top BDII in place • Support for 3 Vos available on many services • net.egi.eu • ipv6.hepix.org • testers.eu-emi.eu • Top BDII condfig file: http://ui2-4.dir.garr.it/IPv6/top-bdii-ipv6.conf
References • EGI Network Support coordination: https://wiki.egi.eu/wiki/NST ( http://net.egi.eu ) • EGI IPv6 http://wiki.egi.eu/wiki/IPv6 • IPv4 address report http://www.potaroo.net/tools/ipv4/index.html • Contact: network-support@mailman.egi.eu