1. Slide 1RMDCN Steering Group, 4-6 June 2008, Vienna 14 th meeting of the RMDCN Operations Committee 3-4 June 2008, Vienna Isabella Weger Head, Computer Division ECMWF isabella.weger@ecmwf.int

2. Slide 2RMDCN Steering Group, 4-6 June 2008, Vienna 14 th Meeting of the RMDCN Operations Committee RMDCN Status Report RMDCN configuration Network Reliability and Performance Service Level Agreement Status of the WIS Report on Tests IPSEC VPN IPv6 Price Review for 2008

3. Slide 3RMDCN Steering Group, 4-6 June 2008, Vienna Migration to MPLS IPVPN technology RMDCN was migrated from Frame Relay to MPLS (Multi-Protocol Label Switching) technology Any-to-any connectivity Class of Service concept Doubling of bandwidth for the basic configuration ISDN backup Improved SLA Migration to MPLS completed on 18 June 2007

4. Slide 4RMDCN Steering Group, 4-6 June 2008, Vienna RMDCN configuration

5. Slide 5RMDCN Steering Group, 4-6 June 2008, Vienna RMDCN Configuration 11 Mission Critical Sites (dual access lines) 1 extra enhanced (dual access lines; single router) 29 ISDN NAS Backup 1 site no Backup (Saudi Arabia) Doubling IP throughput Better Backup Better SLA

6. Slide 6RMDCN Steering Group, 4-6 June 2008, Vienna RMDCN – Availability Service metrics Site Availability (used to be PVC availability in Frame Relay network) SLA 99.9% (100% for Mission Critical sites)

7. Slide 7RMDCN Steering Group, 4-6 June 2008, Vienna Service Problems Audits carried out by OBS Diversity access circuits Diversity of ISDN NAS Backup Ownership of ISDN connection Support issues 24*7 local PTT support Service Desk contact

8. Slide 8RMDCN Steering Group, 4-6 June 2008, Vienna 14 th Meeting of the RMDCN Operations Committee RMDCN Status Report RMDCN configuration Network Reliability and Performance Service Level Agreement Status of the WIS Report on Tests IPSEC VPN IPv6 Price Review for 2008

9. Slide 9RMDCN Steering Group, 4-6 June 2008, Vienna IPSec VPN Tests 2002: IPSec feasibility study guidelines and recommendations for building secure connections over the Internet 2005: IPSec-based VPN as a backup for the RMDCN study Provides a framework for an operational RMDCN backup solution using an Internet-based IPSec VPN Only static rerouting considered 2007-2008: IPSec VPN Backup for the RMDCN project Using and IPSec-based VPN infrastructure to transport operational RMDCN traffic between RMDCN sites as an alternative to the RMDCN network itself Phase #1: Building the IPSec-based infrastructure Phase #2: Using the IPSec-based VPN infrastructure as a backup for the RMDCN in an operational context

10. Slide 10RMDCN Steering Group, 4-6 June 2008, Vienna Test configuration Mimic the NAS ISDN backup implementation within the RMDCN: ECMWF acts as an IPSec centralising site, which guarantees the any-to-any connectivity of the RMDCN IPVPN cloud

11. Slide 11RMDCN Steering Group, 4-6 June 2008, Vienna Manual vs. automatic re-routing

12. Slide 12RMDCN Steering Group, 4-6 June 2008, Vienna Other Technical Solutions - Checkpoint All Checkpoint – 2 Topologies hub-and-spoke topology (Star VPN Community") any-to-any topology ("Meshed VPN Community") if all the gateways are centrally managed, this is easy to implement as the conf would be "pushed" to all the gateways Solution is more suitable for a centralised "Corporate" deployment

13. Slide 13 Cisco IOS solution for building IPsec+GRE VPNs Relies on two proven Cisco technologies Next Hop Resolution Protocol (NHRP) and Multipoint GRE Tunnel Interface Hub-and-spoke All VPN traffic must go via hub; Hub bandwidth and CPU utilization limit VPN Dynamic-Mesh – Dynamic spoke-spoke tunnels Control traffic Hub to Hub and Hub and spoke Data traffic Dynamic mesh Does not alter the standards-based IPsec VPN tunnels, but it changes their configuration Very scalable and easy to configure Other Technical Solutions - DMVPN

14. Slide 14RMDCN Steering Group, 4-6 June 2008, Vienna Spoke A = Dynamic permanent IPsec tunnels Physical: 172.17.0.1 Tunnel0: 10.0.0.1 Spoke B Physical: (dynamic) Tunnel0: 10.0.0.11 Physical: (dynamic) Tunnel0: 10.0.0.12 192.168.0.0/24 10.0.0.1 192.168.2.0/24 Conn. 192.168.0.0/24 10.0.0.1 192.168.1.0/24 Conn. 10.0.0.11 172.16.1.1 10.0.0.12 172.16.2.1 192.168.0.1/24 192.168.1.0/24 10.0.0.11 192.168.2.0/24 10.0.0.12 192.168.0.0/24 Conn. Routing Table 172.16.1.1 172.16.2.1 10.0.0.1 172.17.0.1 (*) NHRP mapping (*NHS) 192.168.2.37/32 ???192.168.2.0/24 172.16.2.1 192.168.1.0/24 172.16.1.1 (l) 10.0.0.1 172.17.0.1 (*) 192.168.1.25/32 ???192.168.1.0/24 172.16.1.1 10.0.0.11 172.16.1.1 10.0.0.12 172.16.2.1 192.168.2.0/24 172.16.2.1 (l) 192.168.1.0/24.1 PC.25 192.168.2.0/24.1 Web.37 ? 192.168.2.0/24 10.0.0.12 192.168.1.0/24 10.0.0.11 ? NHRP Resolution – Process Switching Other Technical Solutions

15. Slide 15RMDCN Steering Group, 4-6 June 2008, Vienna Conclusion from the tests & recommendations The use of shared devices between the RMDCN operational traffic exchange and the IPSec-based backup infrastructure created additional constraints Using dedicated IPSec box should to be considered in an operational environment The use of IPSec devices from different vendors proved to be challenging Consider using one device type or at least one device brand for an operational deployment manual re-routing is time-consuming and prone to mistakes The traffic re-routing has to be fast, automatic and reliable. Only dynamic routing processes can ensure this in an operational environment

16. Slide 16RMDCN Steering Group, 4-6 June 2008, Vienna 14 th ROC: Agreement on Internet backup Backup solution must maintain any-to-any connections Dedicated IPSec equipment needed for RMDCN backup Same type of equipment will be used by all sites Equipment will be managed locally by the sites Portfolio of backup solutions will be RMDCN mission critical sites ISDN NAS backup within the managed network (to be phased out in the future) Backup over the Internet ECMWF will continue to provide a gateway function, so that connectivity between sites using different backup solutions will be maintained

17. Slide 17RMDCN Steering Group, 4-6 June 2008, Vienna Next steps for Internet backup tests Preferred solution is Cisco DMVPN Setup of a test environment for DMVPN including 6 or 7 routers internally at ECMWF If successful, Q4-2008 3 or 4 routers will be sent to volunteers sites to try DMVPN over the Internet. DMVPN will then be used to create the IPSEC VPN solution to backup the RMDCN Q1-2009 results of these tests. If successful, consider recommendation of Cisco Routers using DMVPN for the backup of the RMDCN Otherwise, market survey to find the correct solution Agree on future solution and equipment in ROC-15 (spring 2009)

18. Slide 18RMDCN Steering Group, 4-6 June 2008, Vienna IPv6 Testing Status Update Objectives of IPv6 tests To assess potential benefits and/or problems of deploying IPv6 in an operational environment. To assess IPv6 performance over existing infrastructure. Partners involved CMA (China) CNR (Italy) DWD (Germany) JMA (Japan) KNMI (The Netherlands) SMHI (Sweden) ECMWF

19. Slide 19RMDCN Steering Group, 4-6 June 2008, Vienna Topology for external IPv6 tests

20. Slide 20RMDCN Steering Group, 4-6 June 2008, Vienna Initial results Only a few tests have been completed. Sites did not have any major IPv6 basic connectivity problems with ISPs. Firewalls are ready. Not all applications are IPv6 ready yet, but for the main services such as DNS, web and ftp there is no problem. Plug and play is nice … but requires support staff to really understand IPv6 to solve problems. Performance to/from European sites similar to IPv4, but to/from Asian countries seems a lot better New IPv6 infrastructure is in place but not fully used yet. IPv6 routes may be more efficient than IPv4

21. Slide 21RMDCN Steering Group, 4-6 June 2008, Vienna Situation with the providers and authorities Most of the Internet provider are now IPv6 ready RMDCN Market Survey shown that MPLS Network Operator are IPv6 ready. The use seems quite minimal though EU has recently announced the funding of initiatives in order for IPv6 to represent 25% of the overall traffic exchanged in Europe OECD in a recent report: http://www.oecd.org/dataoecd/7/1/40605942.pdf Is also urging towards IPv6 adoption.

22. Slide 22RMDCN Steering Group, 4-6 June 2008, Vienna What happens next at ECMWF Enable IPv6 operationally on some DMZ subnets. Enable IPv6 operationally on the main Firewalls. Modify ECMWF Dissemination transmission software (ECPDS) to be IPv6 capable (over the Internet). Modify ECACCESS to be IPv6 capable. What will not happen … yet Not planning to deploy on the LAN Not planning to migrate from IPv4 but rather to complement it with additional IPv6 services.

23. Slide 23RMDCN Steering Group, 4-6 June 2008, Vienna 14 th Meeting of the RMDCN Operations Committee RMDCN Status Report RMDCN configuration Network Reliability and Performance Service Level Agreement Status of the WIS Report on Tests IPSEC VPN IPv6 Price Review for 2008

24. Slide 24RMDCN Steering Group, 4-6 June 2008, Vienna MPLS Migration 18 th June 2008 Migration completed Liquidated Damages due to the late delivery of the new Network Failure to meet milestone dates 0.1 % of annual charges per day delay; max. 7% (= 70 days) LDs are a percentage of the first 12 months of Service Charges, so OBS will act on this after 18 June 2008

25. Slide 25RMDCN Steering Group, 4-6 June 2008, Vienna Price Reviews for MPLS network Price Review 2007 First MPLS Price Review was scheduled for 1 April 2007 Offer was 10% on IP Bandwidth Charges only (No reduction on Access Line, Router and Management charges) Overall reduction 5.52% (per site this varied between 0 and 10%) Total Redistribution Charges reduced from ~£14.5K to £9.25K Price Review 2008 Market survey by The Network Collective (a consultancy company) indicated that there should be a significant reduction OBSs first offer is an overall reduction of the charges of 28% (per site this varies between 0% and 58%) No change in Access Line Charges; this is still being addressed with OBS.