1 / 25

14 th meeting of the RMDCN Operations Committee 3-4 June 2008, Vienna

Isabella Weger Head, Computer Division ECMWF isabella.weger@ecmwf.int. 14 th meeting of the RMDCN Operations Committee 3-4 June 2008, Vienna. 14 th Meeting of the RMDCN Operations Committee. RMDCN Status Report RMDCN configuration Network Reliability and Performance

markku
Télécharger la présentation

14 th meeting of the RMDCN Operations Committee 3-4 June 2008, Vienna

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 14th 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 RMDCN Steering Group, 4-6 June 2008, Vienna

  3. 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 RMDCN Steering Group, 4-6 June 2008, Vienna

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

  5. 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 RMDCN Steering Group, 4-6 June 2008, Vienna

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

  7. 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 RMDCN Steering Group, 4-6 June 2008, Vienna

  8. 14th 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 RMDCN Steering Group, 4-6 June 2008, Vienna

  9. 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 RMDCN Steering Group, 4-6 June 2008, Vienna

  10. 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 RMDCN Steering Group, 4-6 June 2008, Vienna

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

  12. 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 RMDCN Steering Group, 4-6 June 2008, Vienna

  13. Other Technical Solutions - DMVPN • 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

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

  15. 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 RMDCN Steering Group, 4-6 June 2008, Vienna

  16. 14th 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 RMDCN Steering Group, 4-6 June 2008, Vienna

  17. 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) RMDCN Steering Group, 4-6 June 2008, Vienna

  18. 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 RMDCN Steering Group, 4-6 June 2008, Vienna

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

  20. 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 RMDCN Steering Group, 4-6 June 2008, Vienna

  21. 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. RMDCN Steering Group, 4-6 June 2008, Vienna

  22. 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. RMDCN Steering Group, 4-6 June 2008, Vienna

  23. 14th 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 RMDCN Steering Group, 4-6 June 2008, Vienna

  24. MPLS Migration • 18th 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 RMDCN Steering Group, 4-6 June 2008, Vienna

  25. 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 • OBS’s 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. RMDCN Steering Group, 4-6 June 2008, Vienna

More Related