LEISTUNGSFÄHIGE FIREWALL SYSTEME AM X-WIN - FRANK BRÜGGEMANN, JENS HEKTOR, ANDREAS SCHREIBER RECHEN- UND KOMMUNIKATIONSZENTRUM, RWTH AACHEN - DFN-PKI

Leistungsfähige Firewall Systeme am X-WiN

  Frank Brüggemann, Jens Hektor, Andreas Schreiber

      Rechen- und Kommunikationszentrum,
                 RWTH Aachen

Agenda

•   RWTH-Uplink zum XWiN Januar 2006
•   Struktur: XWiN-Uplink – Firewallcluster - Peripherieswitches
•   Absehbare Anforderungen -> Konzept zur Steigerung der
    Leistungsfähigkeit und Dienstgüte
•   Migration Uplink auf 10 Gbit/s redundant via BGP
•   Mehrstufiger Ausbau und Optimierung des Firewallclusters
•   Einsatz von Cisco VSS-Systemen
•   Aktuelle Leistungsdaten
•   Ausblick / Wunschzettel / ToDo's

RWTH-XWiN im Januar 2006

•   Uplink in 10 Gbit/s Ethernet, 5
    Gbit/s verfügbare Bandbreite,
    statisch geroutet, single
    homed, nicht redundant
•   Firewallcluster der Firma
    Stonesoft, drei Knoten in
    Gigabit Ethernet
•   Eingebettet in Cisco Catalyst
    6509 Mulitlayer Switches,
    modulares Chassis

Leistungsanforderungen
•   Anfang 2006: mehrere hundert Mbit/s Durchsatz durch das Uplink-System
•   Traffic-MIx: Studierende, Backup, Fileserver...
•   ca. 40% jährlicher Zuwachs des kontinuierlichen Traffics
•   Erhebliche Sondereffekte durch spezielle Nutzergruppen (LHC-Grid!)

•   Plan: Stufenweise Migration aller Uplink-Komponenten auf 10 GbE
•   Gleichzeitige Erhöhung der Dienstgüte / Eliminierung von „Single Points
    of Failure“
•   Herausforderung: Adäquate Technologien befinden sich 2006 teilweise in
    frühen Produktzyklen bzw. sind noch nicht am Markt verfügbar

Der Uplink zum XWiN

•   Steigerung der verfügbaren Bandbreite von 5 Gbit/s auf 10 Gbit/s
•   Redundanz durch Umstellung von statischem Routing auf BGP
•   RWTH ist Single Homed -> privates AS (65011), DFN-Verein AS 680
•   Bereitstellung zweites Interface auf Kundenrouter, BGP Nachbarn auf
    beiden
•   DFN-Verein annonciert das Prefix 0.0.0.0/0 (Default-Route) mit jeweils
    unterschiedlichem MED (Metrik)
•   BGP-Kandidatenroute mit besserer Metrik wird in den Routing Table
    eingetragen, im Rekonvergenzfalle greift die zweite Kandidatenroute
•   Weitgehend redundante Trassenführung vom Kundenrouter in den
    DFN-Backbone

Uplink: Redundanz durch BGP

•   Migrationspfad statisches
    Routing -> BGP entspannt und
    für den Nutzer transparent (AD 20
     vs. 1)
•   Umstellung im Herbst 2006,
    geringer Aufwand, reibungslose
    Zusammenarbeit mit dem DFN-
    Verein
•   Läuft seither stabil und praktisch
    wartungsfrei
•   Zusatznutzen: weitere direkte
    regionale Peeringpartner konnten
    im Nachgang ebenfalls allesamt
    auf BGP umgestellt werden

Migration Firewallcluster

•   Clustersoftware des Herstellers
    Stonesoft / Helsinki
•   Betriebssystem: gehärtetes Linux
•   Hardware selbst beschafft,
    zertifiziert oder unterstützt durch
    Hersteller
•   Zunächst ein zusätzlicher
    Testknoten mit 10 GbE NIC
•   Optimierung der Software für 10
    GbE im Produktivbetrieb in enger
    Zusammen arbeit mit Stonesoft

Migration Firewallcluster II

•   Erfolgreicher Umbau auf 10
    Gbit/s in allen vier Knoten im
    August 2006
•   Stresstests ergeben maximalen
    Durchsatz von ca. 2 Gbit/s
•   CPU-Auslastung Flaschenhals
•   -> weitere Optimierungen
    erforderlich
•   Stonesoft schlägt Umstellung auf
    Layer 2 Multicast basiertes Load
    Balancing vor

Cluster Load Balancing – Modi

•   Virtuelles Clusterinterface mit   •   Virtuelles Clusterinterface mit
    Unicast-MAC in der Firewall           Multicast-MAC in der Firewall
    konfiguriert                          konfiguriert
•   Load Balancing Algorithmus        •   Alle physikalischen Interfaces
    wählt einen Masterknoten aus          der Knoten akzeptieren Multicast-
•   Physikalisches Interface des          Traffic
    Masterknotens arbeitet mit der    •   Statisch generierte Einträge in
    virtuellen MAC-Adresse                arp table und mac address table
•   Traffic, der auf den                  der assoziierten Catalysts
    Firewallcluster geroutet wird,    •   Traffic, der auf den
    wird initial vom Masterknoten         Firewallcluster geroutet wird,
    übernommen und an einen               erreicht alle Knoten, interne
    geeigneten Knoten                     Entscheidung ob zuständig oder
    weitergereicht                        nicht

Multicast Load Balancing - Firewall

Multicast Load Balancing

c6k-xwin#show conf
...
ip route 134.61.0.0 255.255.0.0 134.130.9.230
ip route 134.130.0.0 255.255.0.0 134.130.9.230
ip route 137.226.0.0 255.255.0.0 134.130.9.230
...
arp 134.130.9.230 2122.2222.2224 ARPA
...
mac-address-table static 2122.2222.2224 vlan 108 interface TenGigabitEthernet1/1
TenGigabitEthernet1/3 TenGigabitEthernet2/2 TenGigabitEthernet2/3

Optimierungen Firewall-Cluster II

•   Oktober 2007: 10 GbE NICs von
    Intel in PCI Express Architektur
    verfügbar
•   Labtests von Stonesoft
    vielversprechend
•   Sukzessiver Umbau aller Knoten
    auf PCI Express
•   Maximaler Durchsatz mehr als
    verdoppelt

Erhöhung der Redundanz: Cisco VSS
•   Fortsetzung des Redundanzkonzepts
•   Modulare Cisco 650x Chassis bereits intrinsisch redundant (Netzteile,
    Backplane, Supervisor Engine, Portchannel)
•   Standort nicht „fail safe“: engagiertes Patchen im Uplinkschrank,
    Stromausfall mit Erschöpfung der USV-Kapazitäten, Brand, Flugzeug ...
•   Duplizierung der Systeme aufwändig, Spanning Tree, Next Hop
    Reundancy (VRRP, GLBP) erforderlich, Konfigurationsaufwand
•   Lösung: Cisco VSS – Kopplung zweier physikalischer Chassis Cisco
    6506E mit Sup-720-10GE über einen 10 GbE Portchannel zu einem
    logischen VSS-System

Cisco VSS II

•   Umsetzung erfolgte in
    Januar 2008
•   Konfigurationsaufwand
    gering
•   Systeme laufen seitdem
    stabil in Produktion

Cisco VSS III

•   Physikalische Migration einer
    Uplinkhälfte in Zweitstandort
•   Entfernung Luftlinie ca. 1km
•   Sukzessiver Umbau der
    Sekundärchassis der VSS-
    Systeme und zweier
    Firewallknoten
•   Umbau im Frühjahr 2008,
    Maßnahmen für den Nutzer
    vollkommen transparent

Traffic Snapshot RWTH Uplink

Traffic Snapshot / Smokeping

Wunschliste / ToDo's

• Uplink: Neuen Tarif XI14 ausrollen (20 Gbit/s, 6,67
  Gbit/s Backup)
• Firewallcluster: Kernelupgrade, Hardwareupgrade,
  mehr Knoten -> mehr Kapazität
• VSS: IOS-Upgrade mit ISSU, IPv6, MPLS,...
• Cluster/VSS-System als „building block“ für
  betriebskritische Netzwerksegmente
• Sinnvolle Stresstests zur Ermittlung der maximalen
  Systemleistung

Danke!

Fragen?