Juniper Firefly Perimeter im Labor und freier Wildbahn

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:
   

   Eigenschaft	Wert
   Benötigter vRAM	2GB (Lab only: Man kann bis 1GB runter gehen, mit weniger RAM sind die ge- Interfaces nicht mehr sichtbar)
   Benötigte vCPUs	2
   Max. Zahl NICs	10
   Max. Zonen	128
   Max. Policies	10240 (1024 mit Count)
   Max. Sessions (NAT, FW)	256k
   Max. MAC/ARP-Tabelle	8k
   Max. VLANs	4k
   Max. Zahl OSPF Routen	160k
   Max. Zahl Virtual-Router	5

   
   
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:
   

   Performancekriterium	vSphere	KVM
   Firewall (IPv4, IMIX)	1,2 Gbit/s	0,24 Gbit/s
   Firewall - Neue (TCP)Sessions	26k Sessions/s	9k Sessions/s
   IPSEC (3DES+SHA1, IMIX	66 Mbit/s	33 Mbit/s
   IKE Rate (3DES+SHA1)	83 Tunnel/s	48 Tunnel/s
   Latenz (Firewall, UDP 512Byte)	105us	482us

   
   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/

Richard Müller

Richard Müller ist Geschäftsführer der Proact Deutschland 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.