Transcript ECMWF Status SecRep 14

14th meeting of the
RMDCN Operations Committee
3-4 June 2008, Vienna
Isabella Weger
Head, Computer Division
ECMWF
[email protected]
RMDCN Steering Group, 4-6 June 2008, Vienna
Slide 1
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
Slide 2
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
Slide 3
RMDCN configuration
RMDCN Steering Group, 4-6 June 2008, Vienna
Slide 4
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
Dissemination traffic with FINLAND
390000
180
160
380000
kBytes sent
370000
120
100
360000
80
350000
60
40
340000
20
0
22
M
23 ay
M
24 ay
M
25 ay
M
26 ay
M
27 ay
M
28 ay
M
29 ay
M
30 ay
M
31 ay
M
01 ay
Ju
02 ne
Ju
03 ne
Ju
04 ne
Ju
05 ne
Ju
06 ne
Ju
07 ne
Ju
08 ne
Ju
09 ne
Ju
10 ne
Ju
11 ne
Ju
12 ne
Ju
13 ne
Ju
14 ne
Ju
15 ne
Ju
16 ne
Ju
17 ne
Ju
ne
330000
Date
RMDCN Steering Group, 4-6 June 2008, Vienna
Slide 5
Total time (in minutes)
140
Size
Duration
RMDCN – Availability
 Service metrics
 Site Availability (used to be PVC availability in Frame Relay network)
 SLA 99.9% (100% for Mission Critical sites)
RMDCN availability
According to SLA
Including Backup
100.00%
99.90%
99.80%
99.70%
99.60%
99.50%
Jun-07 Jul-07 Aug-07 Sep-07 Oct-07 Nov-07 Dec-07 Jan-08 Feb-08 Mar-08 Apr-08
RMDCN Steering Group, 4-6 June 2008, Vienna
Slide 6
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
Slide 7
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
Slide 8
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
Slide 9
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
ECMWF
Customer Site
Internet
NAS Domain
NAS
Router
MPLS Cloud
Access
Router
Access Routers
/ CAS routers
Access
Router
Partner Site
RMDCN Steering Group, 4-6 June 2008, Vienna
Slide 10
Manual vs. automatic re-routing
RMDCN Steering Group, 4-6 June 2008, Vienna
Slide 11
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
Slide 12
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
Slide 13
Other Technical Solutions
 NHRP Resolution – Process Switching
= Dynamic permanent IPsec tunnels
NHRP mapping (*NHS)
Routing Table
192.168.0.1/24
Physical: 172.17.0.1
Tunnel0:
10.0.0.1
192.168.0.0/24  Conn.
192.168.1.0/24  10.0.0.11
192.168.2.0/24  10.0.0.12
Physical: 172.16.2.1
(dynamic)
Tunnel0: 10.0.0.12
Physical: 172.16.1.1
(dynamic)
Tunnel0: 10.0.0.11
.1
.25
PC
Web
Spoke B
Spoke A
.1
?
10.0.0.11  172.16.1.1
10.0.0.12  172.16.2.1
192.168.2.0/24
192.168.1.0/24
10.0.0.1  172.17.0.1 (*)
10.0.0.12  172.16.2.1
192.168.1.0/24  172.16.1.1 (l)
192.168.2.37/32
192.168.2.0/24 172.16.2.1
???
10.0.0.1  172.17.0.1 (*)
10.0.0.11  172.16.1.1
192.168.1.0/24
192.168.1.25/32172.16.1.1
???
192.168.2.0/24  172.16.2.1 (l)
192.168.0.0/24  10.0.0.1
192.168.1.0/24  Conn.
192.168.2.0/24  10.0.0.12
RMDCN Steering Group, 4-6 June 2008, Vienna
.37
Slide 14
192.168.0.0/24  10.0.0.1
192.168.1.0/24  10.0.0.11
192.168.2.0/24  Conn.
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
Slide 15
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
Slide 16
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
Slide 17
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
Slide 18
Topology for external IPv6 tests
RMDCN Steering Group, 4-6 June 2008, Vienna
Slide 19
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
Slide 20
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
Slide 21
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
Slide 22
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
Slide 23
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
Slide 24
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
Slide 25