nrw-forschungsnetz im pilot...config am beispiel nexus 7000 / nx-os rwth anbindung interface...

NRW-Forschungsnetzim Pilot

03.03.2016, 64. DFN-Betriebstagung

Markus Speer - WWU Münster, ZIV

Nils Neumann - RWTH Aachen, IT Center

03.03.2016 NRW-Forschungsnetz im Pilot 1

NRW-Forschungsnetz – Hintergrund

Datum „Meilenstein“

AnlassZunehmender Wunsch nach hochschulübergreifenderKooperation im Bereich der IT

Anfang 2015Idee: NRW-Forschungsnetz als „Enabler / Extended LAN “ für hochschulübergreifende Kooperation

1. Halbjahr 2015

• Abstimmung im NRW-Rahmen: IKM-Verantwortliche, RZ-Leiter-Arbeitskreise, DV-ISA

• Gespräche mit dem DFN• Bedarfsumfrage zum NRW-Forschungsnetz

• 25 Rückmeldungen, davon 24 Bedarfsanmeldungen• Mandatierung der WWU Münster durch NRW-Hochschulen

Ende 1. Halbj. 2015

Absprache mit dem DFN: „Pilotierung NRW-Forschungsnetz“:• Weitestgehende Nutzung vorhandener Infrastrukturen• Layer 3 VPN zwischen vier Hochschulen: RWTH Aachen,

Uni Bonn, Uni Duisburg-Essen, WWU Münster

August 2015Projekt-Kickoff: Erörterung netztechnischer Fragestellungen und Use Cases


Projektskizze


Plattform für NRW-Forschungsnetz:DFN Layer 3 VPN-Service

• MPLS auf den XR-Routern im X-WiN

• transparent für den Anwender: d.h. kein MPLS beim Anwender• IP-Schnittstelle auf dem KR des

Anwenders zum MPLS-VPN

• Verwendung von zwei Subinterfaces auf vorhandenem Interface auf KR

1. für X-WiN-Traffic

2. für VPN-Traffic• kein Übergang im VPN zum globalen X-

WiN-Routing!

• BGP auf beiden Interfaces: Annoncieren der Subnetze fürs X-WiN bzw. fürs VPN

• im VPN möglich• Nutzung privater IP-Adressen• Dual Stack IPv4 und IPv6

• Voraussetzung: Anwender-KR am X-WiN


Kundenrouter-Konfiguration für das Layer 3-VPN

interface TenGigabitEthernet2/4

description X-WiN DFN CR-Hannover2 - GE10...

! Hier war vorher native IP-Konfiguration für das X-WiN.

...

interface TenGigabitEthernet2/4.3001

description X-WiN DFN CR-Hannover2

encapsulation dot1Q 3001

ip address 188.1.aaa.bbb 255.255.255.252

...

!

interface TenGigabitEthernet2/4.3002

description X-WiN DFN CR-Hannover2 NRW-Forschungsnetz

encapsulation dot1Q 3002

vrf forwarding RI23HG

ip address 188.1.xxx.yyy 255.255.255.252

...

separate Routing-Instanz


Frames mit VLAN-Tag

Kundenrouter: BGP-Routen im VPN

RouterB#show ip bgp vpnv4 vrf RI23HG neighbors 188.1.xxx.yyy advertised-routes

...

Network Next Hop Metric LocPrf Weight Path

*> 128.176.aaa.bbb/25 172.ccc.ddd.eee 0 64xxx ... ?

...

RouterB#show ip bgp vpnv4 vrf RI23HG neighbors 188.1.xxx.yyy received-routes

....

Network Next Hop Metric LocPrf Weight Path

*> 131.220.aaa.bbb/26 188.1.xxx.yyy 0 680 64xxx ... ?

*> 132.252.aaa.bbb/26 188.1.xxx.yyy 0 680 65xxx ?

*> 134.130.aaa.bbb/25 188.1.xxx.yyy 0 680 47610 i

...


sciebo – www.sciebo.de

• File-Hosting für Hochschulen und Forschungseinrichtungen in NRW

• drei Standorte: Bonn, Duisburg-Essen, Münster (deutsches BDSG)

• 25 teilnehmende Hochschulen

• 40.000 Nutzer

• Plattform: ownCloud

• separate ownCloud-Instanz/IP-Adresse für jede teilnehmende Hochschule

www.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt62/Forum_Mobile_IT_sciebo_Angenent.pdf


https://www.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt62/Forum_Mobile_IT_sciebo_Angenent.pdf

HP 5900 Switch

Loadbalancer 1 Loadbalancer 2

Infiniband-Switch

Datenbank-Server (4x)

Web/App-Server (16x)

X-WiN

132.252.x.y

System-Mgmt. viaJump Host: ssh/rdp

Storage-System (2x)

Netzbereiche:SNS-PUBLIC-DU: 132.252.x.y/28SNS-ETHER-DU: 10.x.y.z/24SNS-INFINI-DU: 10.x.y.z/24SNS-MGMT-SSH-DU: 10.x.y.z/24SNS-MGMT-IMM-DU: 10.x.y.z/24SNS-HEARTBEAT-DU: 10.x.y.z/24

132.252.x.yeth1

MGMT(SSH+IMM)

HP25SNS-DU10.x.y.z

C941SNS-UNI-DUE-ETH0

UniDuisburg-Essen

132.252.x.y

48

PDU

TS

10.x.y.z

Backend-Server

sciebo-StandortDuisburg-Essen(exemplarisch)

HP59SNS-DU


Das Sciebo-Konstrukt an einem Standort

• nach außen weitgehend eine Black-Box

• Load Balancer• Layer 3 Router

• NAT-Funktionalität für die Backend-Server

• keine Anbindung der Backend-Systeme (Server, Netzkomponenten) an das Campus-Netz der gastgebenden Einrichtung

• Verwendung privater IP-Adressen

• Betrieb durch ZIV der WWU Münster

• Management• Netzmanagement: Site-to-Site-VPN zur WWU Münster

• Systemmanagement: Jump Host


• Ursprüngliches sciebo-Design: Verzicht auf Datensicherung

• Idee: ringförmige Datenspiegelung

• bei Datenverlust an einem Standort• Verfügbarkeit der Daten an einem anderen Standort ohne zeitaufwändige

Restaurierungsmaßnahmen

• transparent für den Nutzer

• Datenspiegelung durch direkte Kommunikation der sciebo-Backend-Server an den verschiedenen Standorten untereinander

• Verfahren: rsync

Bonn

MünsterEssen

Use Case: sciebo-Datenspiegelung


rsync

HP5900

LB 1 LB 2


X-WiN

10.x.y.z/24zusätzl.: 128.176.x.y/25


BackboneMünster

BackboneBonn

Backbone Duisburg-Essen

HP5900

LB 1 LB 2



NRW-Forschungsnetz

KR

XR

…

HP12508 C6509

10.x.y.z/24zusätzl.: 131.220.x.y/26

Routing-InstanzACLs

Routing-InstanzACLs

Anbindung des sciebo-Backend-Netzes SNS-ETHER an NRW-Forschungsnetz


Änderungen für Anbindung des sciebo-Backend-Netzes SNS-ETHER an das NRW-Forschungsnetz

• HP5900 Switch• Redundante Verbindung (2x10GE LACP) mit Campus-Router der

gastgebenden Einrichtung

• Definition einer Layer 3 Routing Instanz

• 1 RAGG-Interface (Routed Aggregation) zum Campus-Router

• 1 VLAN-Interface für Backend-Netz SNS-ETHER

• Routing zu den NRW-VPN-Netzen :

• in Münster: OSPF

• In Bonn und Duisburg-Essen: statische Routen

• ACLs, die nur die Kommunikation zwischen den NRW-VPN-Netzen erlauben

• Backend-Server• Zusätzliche Öffentliche IP-Adressen für Backend-Netz SNS-ETHER aus dem

jeweiligen Standort

• statische Routen zu den anderen drei NRW-VPN-Netzen zum HP5900


Integration des sciebo-Backends in das Backbone


Netzstruktur in Bonn für sciebo-Datenspiegelung


Erfahrungen

• Layer 3 VPN• Konfiguration nur auf den ASR 9000 CRs in Hannover und Frankfurt (d.h.

nicht auf den lokalen C7609 XRs)

• Verwendung identischer privater AS-Nummern bei den VPN-Teilnehmern

• „BGP Loop Detection“ schlägt zu und verhindert Akzeptieren der Route

• Cisco IOS Feature „as-override“ auf den X-WiN CRs hat geholfen

• Abstimmung der BGP-Routen untereinander und mit dem DFN-NOC wg. Filterung

• Kopplung der sciebo-Backend-Netze über die Campus-Netze der gastgebenden Einrichtung• Wg. der restriktiven Routing/ACL-Konfiguration auf den HP5900 hat die

gastgebende Einrichtung nur äußerst beschränkte Diagnosemöglichkeiten.

• Abstimmungsbedarf bzgl. ACLs

• Use Case „sciebo-Datenspiegelung“• erste Performance-Tests mit rsync zwischen zwei Servern: 1,6 Gbit/s


Use Case der RWTH Aachen: „sciebo-Backup“

• Sicherung von besonders wertvollen in sciebo gespeicherten Daten außerhalb von sciebo• z.B. aufwändig erzeugte Forschungsdaten

• Entwicklung eines generischen TSM-basierten Datensicherungsverfahrens

• Zugriff vom TSM-Clienten in Aachen über NRW-VPN auf die sciebo-Backend-Server in Bonn

• Nutzung der für die sciebo-Datenspiegelung aufgebauten Infrastruktur


Bonn

sciebo

Aachen

TSM

Ausgangslage an der RWTH Aachen

- Folgende VPN Konfiguration kann auch für andere VPNs verwendet werden

- Ausgangslage- Anbindung an 2 Standorte via BGP

- Reduktion der Ausfallszeiten durch BFD (Bidirectional ForwardingDetection)

- Verwendete Router: 2x Nexus 7010er

- Größe der Routingtabelle, ca. 200000 Einträge

- Optimierung der Latenz: Ziel günstiger über Frankfurt oder Hannover erreichbar

- Nutzer des HEPPI (High-Energy Physics Published Information) – VPNs

- Ziel- Aufschaltung ohne Downtime

- Minimale Konfigurationsänderungen zur Vermeidung von Fehlern


Anbindung eines weiteren VPNs

- Es gibt schon ein VPN

- Separate Auskopplung direkt an den Standorten Frankfurt/Hannover

- NRW-Forschungsnetz könnte analog aufgesetzt werden

ABER

- Unnötige Limitierung der Bandbreite

- Skalierungsmöglichkeit äußerst begrenzt; 5 Leitungen pro Standort

- Wenig zukunftsfähig bei Migration von 10x10G zu 2x100G


Tests mit NX-OS (Nexus 7000) / IOS (Catalyst 6500)

Idee: VLANs für VPNs einfach ‚durchswitchen‘, d.h. Weiterleitung getaggter Frames eines Subinterfaces zu einem anderen Interface:

- Catalyst 6500- c6k-test(config-subif)#encapsulation dot1Q 666- Command rejected: VLAN 666 not available

- Nexus 7000- Config wird ohne Fehlermeldung genommen

Jedes weitere VPN benötigt

nur noch ein VLAN (zuvor

ein eigenes Kabel)


Neues Konzept …

- Erste Variante funktioniert nicht …

- Routed Port-Channels werden beibehalten- gute Unterstützung von BFD

- (SVI nur rudimentär unterstützt)

- eigenes Subinterface pro VPN

- alle Pakete werden getaggt (802.1q)

- jedes VPN erhält sein eigenes VRF (Virtual Routing and Forwarding)- der ‚normale‘ Datenverkehr im default VRF

- iBGP auf allen internen Links


Anbindung der VPNs HEPPI / NRW Forschungsnetz


Anbindung der VPNs HEPPI / NRW Forschungsnetz

NRW-Forschungsnetz im Pilot03.03.2016 22

Config am Beispiel Nexus 7000 / NX-OS

RWTH Anbindung

interface port-channel1.1bfd interval 100 min_rx 100 multiplier 3description DFN-HAN-RWTHmtu 9202encapsulation dot1q 3003ip access-group in.XWiN-External inip flow monitor xwin inputno ip redirectsip address 188.1.242.98/30ipv6 address 2001:638:c:a101::2/64no ipv6 redirectsip pim sparse-modeno shutdown

VPN HEPPI

interface port-channel1.2description DFN-HAN-HEPPImtu 9202encapsulation dot1q 3004vrf member heppiip flow monitor xwin inputip address 188.1.153.50/30no shutdown

VPN NRW-Forschungsnetz

interface port-channel1.3description DFN-HAN-NRWmtu 9202encapsulation dot1q 3005vrf member nrwip flow monitor xwin inputip address 188.1.248.102/30no shutdown

Port-channel

interface port-channel1bfd interval 100 min_rx 100 multiplier 3description DFN-HANmtu 9202


Projektmeilensteine

Datum Meilenstein

August 2015 Projekt Kick-off-Meeting

November 2015 Konfiguration des NRW-VPN im X-WiN durch das DFN-NOC

Dezember 2015

Pilotteilnehmer an das NRW-VPN angeschlossen (CR-Router)• RWTH Aachen (2x): reales Subnetz im NRW-VPN• Uni Bonn (2x): nur Announcing des sciebo-Backend

Subnetzes, Testadresse• Uni Duisburg-Essen (1x): nur Announcing…• WWU Münster (1x): nur Announcing…

Februar 2016 Realer Anschluss der drei sciebo-Backend Subnetze

ToDo

Use Cases• sciebo-Datenspiegelung• sciebo-Backup• …

Vielen Dank an alle Beteiligten!


Vielen Dank für Ihre Aufmerksamkeit!


nrw-forschungsnetz im pilot...config am beispiel nexus 7000 / nx-os rwth anbindung interface...

Documents