Juniper Firefly Perimeter im Labor und freier Wildbahn

This entry is part 4 of 8 in the series Aus den teamix Labs

Seit Anfang des Jahres gibt es nun von Juniper Networks offiziell eine SRX Firewall als virtuelle Maschine unter dem toll klingenden Namen Firefly Perimeter. Diese virtuelle Maschine, welche man per OVA (Open Virtualisation Archive) einfach deployen kann, hat es ziemlich in sich, da man damit sehr flexibel agieren und sehr viel Blech beim Kunden oder auch im Labor einsparen kann.

Wir bei teamix setzen Firefly Perimeter sowohl für Tests im Labor als auch im wirklichen Leben ein und würden gerne einfach mal unsere Erfahrungen mit Euch teilen, da es gerade im Bereich „Netzwerke“ nach wie vor sehr viele Skeptiker bei der Virtualisierung von Komponenten gibt:

  1. Preis und Lizenzierung
    Lizenziert wird die Firefly Perimeter nach verwendeten Cores (vCPUs), welche entweder jährlich oder einmalig lizenziert werden können.
    Mögliche Lizenzierungsschritte sind 2,10,100,1000 Cores.
    Beispielsweise kostet die kleinste 2-Core Basisversion 2.800 USD Listenpreis(!) (ca. 2000 EUR-  Stand Ende Mai 2014).
  2. Technik und Anforderungen
    Das Deployment einer vSRX bzw. Firefly Perimeter ist denkbar einfach:

    1. Lizenzen hier kaufen und bezahlen. 🙂
    2. OVA-Image hier runterladen.
    3. OVA-Image Deployen.
    4. VM-Image anpassen (NICs, vCPUs, …)
    5. VM anschalten.
    6. Warten bis JunOS Login kommt. Fertig!

    In der Praxis sind folgende Limits und Anforderungen interessant:

    EigenschaftWert
    Benötigter vRAM2GB
    (Lab only: Man kann bis 1GB runter gehen,
    mit weniger RAM sind die ge- Interfaces nicht mehr sichtbar)
    Benötigte vCPUs2
    Max. Zahl NICs10
    Max. Zonen128
    Max. Policies10240 (1024 mit Count)
    Max. Sessions (NAT, FW)256k
    Max. MAC/ARP-Tabelle8k
    Max. VLANs4k
    Max. Zahl OSPF Routen160k
    Max. Zahl Virtual-Router5

  3. Performance
    Praxiserfahrungen haben wir nur mit vSphere als Hypervisor gemacht. Es gibt die Firefly Perimeter aber auch als KVM-VM, die sicherlich weniger gut performen wird wie die vSphere Variante (KVM ist ziemlich schlecht im Vergleich zu vSphere was den Netzwerkstack angeht). Juniper gibt hier folgende offziellen Werte an:
    PerformancekriteriumvSphereKVM
    Firewall (IPv4, IMIX)1,2 Gbit/s0,24 Gbit/s
    Firewall - Neue (TCP)Sessions26k Sessions/s9k Sessions/s
    IPSEC (3DES+SHA1, IMIX66 Mbit/s33 Mbit/s
    IKE Rate (3DES+SHA1)83 Tunnel/s48 Tunnel/s
    Latenz (Firewall, UDP 512Byte)105us482us

    Wir können diese Werte für vSphere bestätigen und setzen selbst bis 750Mbit/s Firewall und 50Mbit/s VPN die Firefly Perimeter gerne ohne weitere Performancetests  in der Praxis ein.
  4. Weitere Unterschiede zu physikalischen SRX-Firewalls
    Es ist erklärtes Ziel von Juniper, dass so viel wie möglich auf der Firefly Perimeter mit einer physikalischen SRX gleich ist. Im wirklichen Leben ist uns noch nichts untergekommen was wir mit einer Firefly Perimeter machen wollten und nicht möglich war (Ausnahme im Labor: Fragmentierung bei GRE-Tunneln, siehe weiter unten). Unter folgendem Link gibt es eine detaillierte Liste mit Dingen die sich dennoch zum physikalischen Blech unterscheiden.
  5. Einsatzgebiet „Laborumgebung“
    Ja, wir kennen zwar auch Junosphere, was ein ziemlich geniales „Lab aus der Cloud“ von Juniper ist, aber um mal eben schnell eine Kleinigkeit nachzu-(schauen|bauen) ist die vSRX auch ziemlich genial.
    Folgende Dinge konnten wir erfolgreich im Labor mit der vSRX ausprobieren ohne irgendwelche Physik zum Testen zu benötigen:

    1. OSPF-Grundlagen Labor mit BFD, ECMP, MD5, …
      Kleiner Grundlagensetup für die Ausbildung im Bereich Netzwerke – hier kann auch schnell und einfach die eine odere andere Detailfrage (Wie war das nochmal mit der NSSA?) geklärt werden.
    2. BGP-Signalisiertes L2VPN und L3VPN
      Hier haben wir unseren Internet Exchange Point „N-IX“ (http://www.n-ix.net/) testweise im Labor mit VPLS nachgebaut, da wir das nach aktuellem Stand für demnächst planen – Final natürlich nicht auf Basis vSRX – hier sind eher doch echte MX/QFX-Systeme notwendig. Schliesslich wollen wir dann gleich mit 40GE an den Start. 😉
      Einen kleinen Einblick gibt das zum Artikel gehörige Video, welches eine der Labor-vSRXen etwas detaillierter zeigt.
    3. MPLS over GRE over IPSec.
      Hier besteht aber die kleine Ausnahme, dass eine vSRX keine Fragmentierung von GRE-Tunneln beherrscht, also mussten wir hier doch auf „echte SRXen“ zurückgreifen.
  6. Einsatzgebiet „Hosted Firewall/VPN“
    Bei unserer BackupAsAService Lösung Flexvault benötigen viele unserer Kunden ein VPN welches wir auch mit IPSec anbieten. Hier ist die Firefly Perimeter ideal, da wir natürlich die Betriebskosten (Rack, Strom, Abschreibung) möglichst gering halten wollen und die Firefly Perimeter ausreichend Performance liefert.
    Die Firefly Perimeter bieten wir sowohl bei uns im Datacenter als auch bei unseren Kunden an und sind sehr zufrieden mit der Gesamtlösung. Hier haben wir auch schon konstante VPN-Werte um die 100Mbit/s im Regelbetrieb gesehen.

Wenn noch irgendwelche Fragen bestehen: Einfach einen Kommentar hinterlassen oder bei uns melden und eine kostenlose „Teststellung“ vereinbaren.

 

Video mit dem Boot einer Firefly Perimeter aus unserem VPLS Lab:

Hinweis:
Das Video enthält mindestens zwei offensichtliche Fehler.
Wer diese zuerst findet und als Kommentar hier postet, erhält ein kleines Dankeschön von uns.

 

Update 01 – „VRRP geht nicht“ – Stand 11/2014 bzw.Junos 12.1X46/47

Im Lab konnten wir nachvollziehen, dass VRRP auf Firefly Perimeter leider nicht fuktioniert. Der Hintergrund ist aller Wahrscheinlichkeit nach der, dass die beiden vSRX-Systeme sich auf eine IETF-konforme VRRP-MAC einigen (00:00:5e:…) die VMWare trotz „vSwitch-Tuning“ (Promisc, MAC-Change, Spoofing erlaubt) nicht wirklich akzeptiert.
Ein Linux-System mit VMWare-konformen MACs zeigte diese Probleme nicht.

Details dazu finden sich im von uns ins Leben gerufene PR1038466, der leider (noch) nicht öffentlich ist.

Spannend ist auch, dass VRRP laut diesem Dokument (Seite 20)  supported ist, aber trotzdem nicht geht. Hier findest sich auch ein Hinweis auf die PRs 917549 und753715, welche leider (noch) nicht öffentlich einsehbar sind. Das zeigt mal wieder das Testen und Erfahungswerte neben dem klassischen „Herstellerangaben lesen“ gerade in der IT einen sehr hohen Stellenwert haben.

 

Links zum Artikel:

Firefly Perimeter Download: https://www.juniper.net/support/downloads/?p=firefly#sw

Firefly Perimeter Features: http://www.juniper.net/techpubs/en_US/firefly12.1×46-d10/topics/reference/general/security-virtual-perimeter-feature-support-vmware.html

Nürnberger Internet Exchange: http://www.n-ix.net/

Series Navigation<< Optischer Interconnect mit Branch SRX FirewallsLatenzen richtig messen und verstehen >>

Richard Müller

Richard Müller ist Gründer und Geschäftsführer der teamix GmbH.
Den „kreativen“ Umgang mit Computern und Datennetzen lernte er schon im Schulalter. Bis heute hat Richard eine Begeisterung für technisch brilliante Konzepte und Lösungsansätze in den Bereichen IT-Infrastruktur – hier vor allem alles rund ums Netzwerk.

 
Kommentare

Ich liebe die Firefly und hatte dazu im März mal was geschrieben (http://www.vcloudnine.de/juniper-firefly-perimeter/). Ich nutze sie gerne für Tests und im Lab. In der Wildbahn habe ich noch keine ausgesetzt, aber das kann nicht mehr lange dauern. Use cases gibt es bereits einige.

Richard Müller
Richard Müller

Hallo Patrick!
Ich liebe die Firefly auch sehr, gerade weil sie uns hilft Dinge geschwind mal zu testen ohne ins echte Lab an eine MX gehen zu müssen. Wie schon geschrieben ist das Teil auch wirklich gut im echten Leben einsetzbar. Wir implementieren beispielsweise damit demnächst eine VPN-Verbindung nach Asien, da wir dort zu wenig Blech wie möglich stehen haben wollen und der Kunde sowieso ESX-Hosts dort hat. Frei nach dem Motto der Autopuristen: Was nicht da ist, kann nicht kaputt gehen. 🙂

Lösung: Die Uptime passt nicht zur Dauer des Videos!!! Hat da jemand an der Uhr gedreht?

Hinterlassen Sie einen Kommentar