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.

RMDCN Steering Group, 4-6 June 2008, Vienna Slide 1

14th meeting of the RMDCN Operations Committee

3-4 June 2008, Vienna

Isabella Weger

Head, Computer Division

ECMWF

[email protected]


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


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 configuration


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

330000

340000

350000

360000

370000

380000

390000

Date

kB

yte

s s

en

t

0

20

40

60

80

100

120

140

160

180

To

tal ti

me (

in m

inu

tes)

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

99.50%

99.60%

99.70%

99.80%

99.90%

100.00%

Jun-07 Jul-07 Aug-07 Sep-07 Oct-07 Nov-07 Dec-07 Jan-08 Feb-08 Mar-08 Apr-08

According to SLA Including Backup


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







IPSEC VPN

IPv6



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


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

MPLS Cloud

NAS Domain

ECMWF

Access Routers/ CAS routers

Customer Site

AccessRouter

NASRouter

AccessRouter

Partner Site

Internet


Manual vs. automatic re-routing


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


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


Spoke A

= Dynamic permanent IPsec tunnels

Physical: 172.17.0.1Tunnel0: 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.1192.168.1.0/24 Conn.

10.0.0.11 172.16.1.110.0.0.12 172.16.2.1

192.168.0.1/24

192.168.1.0/24 10.0.0.11192.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.1192.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.110.0.0.11 172.16.1.110.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.12192.168.1.0/24 10.0.0.11

?

NHRP Resolution – Process Switching

Other Technical Solutions


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


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


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)


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


Topology for external IPv6 tests


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


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.


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.







IPSEC VPN

IPv6



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


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.

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.

Documents

rmdcn steering group

rmdcn network

rmdcn sites

rmdcn study

rmdcn project

rmdcn ipvpn cloud slide

operational rmdcn traffic

ipsec vpn backup