Knowledge Base Konfiguration WAN Optimization

Transkript

1 Datum 19/01/ :17:00 Hersteller Fortinet Modell Type(n) Aktuelle Fortigates mit Harddisk, FortiClient Firmware FortiOS v4.0 / v4.1 Copyright Boll Engineering AG, Wettingen Autor Sy Dokument-Version 1.0 Inhaltsverzeichnis WAN Optimiziation - Basics... 2 Unterstützte Geräte... 2 Unterstützte WAN Optimization Technologien... 2 Hinweise... 4 Konfiguration... 5 Konfiguration Full Optimization zwischen zwei Fortigates... 5 Konfiguration WebCaching mit Active/Passive- oder PeerToPeer Rule Konfiguration WebCaching Only zwischen Fortigates und FortiClient Überwachung der WAN Optimization Anhang Grösse der internen Festplatten WAN Optimization Test mit Durchsatzzahlen... 18

2 WAN Optimiziation - Basics Mit der FortiOS v4.0 Version ist die neue Funktion WAN Optimization hinzugekommen. In diesem Artikel soll beschrieben werden, was das WAN Optimization von Fortinet leistet und wie es konfiguriert wird. Unterstützte Geräte Es werden alle aktuellen Geräte unterstützt, die über eine Harddisk verfügen: - FG51B - FWF81C/FG82C - FG111C - FG311B - Sowie alle Modelle mit freiem AMC- oder FSM-Slot Weiterhin unterstützt der FortiClient ab der Version v4.0 das WAN Optimization. Unterstützte WAN Optimization Technologien Protocol Optimization Über spezielle Techniken wird versucht, den benötigten Traffic für bestimmte Protokolle zu reduzieren. Insbesondere sehr geschwätzige Protokolle, die vornehmlich für LAN Traffic entwickelt wurden, wie z.b. CIFS, profitieren hiervon sehr stark. Ein konkretes Beispiel für eine solche Optimierung ist z.b. das Senden eines selektiven ACK ( SACK ). Hierüber kann beim Paketverlust der Empfänger dem Absender genau mitteilen, welche Pakete angekommen sind, so dass dieser nur die verloren gegangenen Pakete und nicht sämtliche Pakete des Windows neu senden muss. Die Protokoll Optimierung arbeitet nur für spezifische Protokolle. Zurzeit unterstützt die Fortigate HTTP, CIFS, FTP, MAPI und TCP im Allgemeinen. Byte Caching Das Byte Caching kann eine massive Datenreduktion bewirken, wenn die gleiche Datei mehrfach zwischen zwei Fortigates übertragen wird. Hierfür wird die zu übertragende Datei in Segmente ( Chunks ) aufgeteilt. Für jedes Segment wir dann ein sogenannter Hashwert gebildet. (Hashwerte haben die Eigenschaft, dass gleiche Datensegmente immer gleiche Hashwerte bilden, unterschiedliche Datensegmente dagegen immer unterschiedliche Hashwerte ergeben. Darüber hinaus sind Hashwert wesentlich kleiner als das dazugehörende Datensegment.) Das Datensegement und der dazugehörige Hashwert werden auf der internen Festplatte im Dictionary gespeichert. Für die Übertragung der Datei sendet die Fortigate nun nicht das eigentliche Datensegment, sondern nur den viel kleineren Hashwert. Kennt die empfangene Fortigate diesen Hashwert, findet sie den Hashwert und das dazu gehörige Datensegment in ihrem eigenen Dictionary. D.h. sie kann nun das eigentliche Datensegment an den internen Empfänger schicken. Kennt sie den Hashwert aber noch nicht, so muss sie der sendenden Fortigate Bescheid geben, dass doch das richtige Datensegment geschickt werden muss. Sobald sie dieses bekommen hat, kann sie es mit dem dazu gehörigen Hashwert in ihrem Dictionary ablegen. Bei der nächsten Datenübertragung dieses Segments wird es dann reichen, nur den Hashwert zu übertragen. Seite 2 von 21

3 Knowledge Base Das Caching der Dateisegmente findet hierbei auf Byte-Ebene Byte Ebene statt. D.h. es ist der Fortigate prinzipiell egal, ob die Datei z.b. über SMTP oder HTTP übertragen wird in beiden Fällen greifen die gleichen Dictionary Einträge. Web Caching Das Fortigate Webcaching funktioniert ähnlich dem herkömmlichen Webcaching. Das Webcaching arbeitet Objekt-basierend (HTML-Seiten, Seiten, Bilder, Servlet-Antworten Servlet etc.). Das Web Caching der Fortigate funktioniert sowohl als normales Webcaching (d.h. die Fortigate cached die Server Antworten auf Anfragen der internen Clients) als auch als reverse Webcaching (d.h. die Server Antworten worten des eigenen internen Webservers werden für die Anfragen der externen Clients gecached). Seite 3 von 21

4 Hinweise Proprietäre Technologie Die WAN Optimization Technologie von Fortinet ist proprietär. Für die Konfiguration braucht man auf jeder Seite (z.b. Headquarter und BranchOffice) jeweils eine Fortigate (resp. einen FortiClient). Es können keine anderen WAN Opt Geräte verwendet werden. Einzige Ausnahme ist das WebCaching. Hier benötigt man kein zweites WAN Opt Gerät. Nicht zusammen mit einem Protection Profile nutzbar Derzeit (bis v4.1) ist es nicht möglich, WAN Optimization auf Traffic anzuwenden, der über eine Firewall- Regel mit Protection Profile über die Fortigate geleitet wird. Es wird nur Traffic optimiert, der ohne Protection Profile über die Fortigate fliesst. Möchte man dennoch eine Funktion des Protection Profiles (z.b. AV scanning) nutzen, so ist dieses derzeit nur mit VDOMs realisierbar. Die Fortigate muss dafür in zwei VDOMs aufgeteilt werden, welche über einen VDOM Inter-Link hintereinander geschaltet werden. Auf der inneren VDOM kann dann das Protection Profile konfiguriert werden, die äussere VDOM übernimmt das WAN Optimization. Seite 4 von 21

5 Konfiguration Prinzipiell ist die Konfiguration des WAN Optimization eine zusätzliche Konfiguration. Das heisst, es müssen weiterhin die entsprechenden Firewall-Regeln vorhanden sein. Kann Traffic nicht durch die Fortigate fliessen, da keine FW-Regel vorhanden ist, so wird auch kein WAN Optimization angewendet. Die WAN Optimization Rules, die im folgenden vorgestellt werden, ersetzen nicht die normalen Firewall Rules. Die Konfiguration des WAN Optimization unterscheidet sich je nach dem, welche Optimierungstechniken eingesetzt werden sollen. Fürs das Protocol Optimization und Byte Caching werden auf beiden Seiten je eine Fortigate benötigt hierfür wird das Full Optimization konfiguriert. Für das Webcaching allein wird nur eine Fortigate verwendet und es muss lediglich das Web Caching Only konfiguriert werden. Folgende drei Fälle werden in diesem Artikel behandelt: - Konfiguration des Full Optimization (Protocol Optimization, Byte Caching mit/ohne Webcaching) - Konfiguration WebCaching Only - Konfiguration des Full Optimization zwischen Fortigate und FortiClient Konfiguration Full Optimization zwischen zwei Fortigates Für die Full Optimization können zwei grundlegende Infrastrukturen unterschieden werden: - Active-Passive Mode: WAN Optimization zwischen einem Headquarter und mehreren Aussenstellen - Peer-to-Peer Mode: WAN Optimization zwischen genau zwei Lokationen Active-Passive Mode: Abbildung 1: Netzwerkskizze für folgendes Beispiel (es werden nur die Konfiguration vom Headquarter und BranchOffice1 betrachtet) Dieser Modus wird in zwei Schritten konfiguriert: Seite 5 von 21

6 1. Konfiguration der Peers 2. Konfiguration der WAN Opt Rules Die sonstige Konfiguration der Fortigate ändert sich nicht. Es ist also weiterhin notwendig, dass für den Traffic der WAN optimiert werden soll auch entsprechende Firewall-Regeln vorhanden sind. 1. Konfiguration der Peers Jede Fortigate, die an der WAN Optimierung teilnehmen soll, muss als Peer definiert werden und den anderen Fortigates bekannt gemacht werden. Ein Peer definiert sich durch eine Local Host ID und seine IP (, welche von den anderen Fortigates gesehen wird). Der Name, der als Local Host ID verwendet wird, ist der Name, der von den anderen Fortigates als Peer Host ID verwendet wird. Die lokale IP brauchen Sie nicht einzugeben, da automatisch die IP von dem Interface verwendet wird, über welches der entsprechende Peer erreicht wird. Abbildung 2: Peer Konfiguration - Headquarter Abbildung 3: Peer Konfiguration - BranchOffice1 Bitte nicht vergessen, den Apply-Button oben rechts zu drücken, nachdem die Local Host ID angegeben wurde. 2. Konfiguration der WAN Opt Rules Seite 6 von 21

7 Die Rules unterscheiden sich, je nach dem auf welcher Seite die Fortigate steht. Auf der BranchOffice Seite müssen typischerweise Active -Rules definiert werden. Eine Active -Rule braucht es immer auf der Seite, auf der die Verbindung, welche über das WAN Optimization läuft, geöffnet wird, also auf der Client-Seite. Mit der Active -Rule wird genau bestimmt, auf welchen Traffic welche Art von WAN Optimization durchgeführt wird. Abbildung 4: Active Rules auf Client-Seite Source- /Destination Address: Hier werden die Adressen der Clients (Source) und der Server (Destination) an. Anmerkung zu den Adressen: Adressen können Sie in der Form von einzelnen IP-Adressen, Subnetzen oder IP-Ranges angeben. Lassen Sie sich bitte nicht von der eigentümlichen Darstellung der Adressen in der Rule- Uebersicht irritieren. Am besten geben Sie bei der Eingabe einer neuen Rule die Adressen in dem Format ein, wie Sie es bei der Erstellung von Adressvariablen für Firewall-Rules gewohnt sind. Einzige Ausnahme ist die Adresse /0 diese muss bei den WAN Opt Rules mit angegeben werden. Port: Als Port werden die gewünschten Server Ports angegeben. Soll Protokoll-Optimierung in dieser Rule genutzt werden (Feld: Protocol ), so darf nur der Port für dieses Protokoll eingeben werden (z.b. Port 445 für Protokoll CIFS). Würde hier ein Port Range eingeben und gleichzeitig CIFS aktiviert werden, so würde die Fortigate versuchen, den Traffic auf allen Ports der Port Range mit CIFS zu beschleunigen. Auto-detect: Damit die Rule als Active Rule arbeitet, muss hier entsprechend Active ausgewählt werden. Protocol: Es wird das gewünschte Protokoll für die Protokoll Optimierung ausgewählt. Es muss darauf geachtet werden, dass im Feld Port auch der entsprechende Port für dieses Protokoll gewählt wurde. Transparent Mode: Seite 7 von 21

8 Wenn diese Option aktiviert ist, bleibt die IP-Adresse vom Client unverändert. Der Server sieht also den Client so, als ob kein WAN Optimization durchgeführt wird. Ohne den Transparent Mode sieht der Server als Absender die Fortigate von seiner Seite anstatt die IP-Adresse des Clients. Dieses kann in bestimmten Situationen das Routing erleichtern. Für CIFS ist das Aktiveren dieser Option jedoch zu empfehlen. Enable Byte Caching: Um Byte Caching für den Traffic dieser Rule zu nutzen, muss diese Option aktiviert werden Enable SSL: Ueber diese Option kann SSL Offloading auf der Fortigate aktiviert werden. Weitere Informationen finden Sie im WAN Optimization Guide ( Enable Secure Tunnel: Mit dieser Option wird der WAN Optimization Tunnel per AES-128 verschlüsselt. Um die Verschlüsselung zu nutzen, muss zusätzlich noch eine Authentication Group konfiguriert und ausgewählt werden. Diese Verschlüsselung ist jedoch nicht vergleichbar mit einem IPSec-Tunnel, da im Falle der PreShared Keys eine statische Verschlüsselung (ohne wechselnden Schlüssel) stattfindet. Weitere Informationen finden Sie im WAN Optimization Guide ( Authentication Group: Diese Funktion ist für zwei Fälle sinnvoll: Zum einen muss eine Authentication Group angegeben werden, wenn die Option Enable Secure Tunnel aktiviert wurde. Zum anderen können mit der Authentication Group Peers sicher (=authentifiziert) in das WAN Optimization Umfeld eingebunden werden, wenn dieses Peers keine fixe IP Adresse haben, mit der sie als Peer definiert werden können. Dieses ist insbesondere für FortiClients notwendig (s. Abschnitt mit FortiClients), aber auch wenn Fortigates an den Branch Offices installiert sind, die keine fixe IP Adresse besitzten. Auf der Seite des Headquarters (Server-Seite) wird dagegen eine entsprechende Passive -Rule benötigt. Bei den Passive Rules werden nur noch Adressen und Ports angegeben, aber keine WAN Optimierungstechniken. Die passiven Rules übernehmen einfach die von der Active-Rule angegebenen Techniken. Abbildung 5: Passive Rule auf Server-Seite Mit geeigneten Passive-Rules können gleichzeitig mehrere Active Rules abgedeckt werden (in dem hier eine Port-Range angegeben wird anstatt für jeden Port eine einzelne Rule zu erzeugen). Ebenfalls können je nach Adressierung der BranchOffice Netzwerke auch mit einer einzelnen Passive Rule mehrere BranchOffices abgedeckt werden. Seite 8 von 21

9 Sofern mehrere Rules auf einer Fortigate konfiguriert werden, muss auf die korrekte Reihenfolge geachtet werden. Die Rules werden von der Fortigate von oben nach unten abgearbeitet. Die erste passende Rule (Source-, Destination Address und Port müssen stimmen) wird verwendet. Peer-to-Peer Mode: Abbildung 6: Netzwerkskizze für nachfolgendes Peer-to-Peer Beispiel Der Peer-to-Peer Mode wird typischerweise zur WAN Optimization zwischen genau zwei Fortigates genutzt, ist ansonsten aber ähnlich zum Active-Passive Mode aufgebaut. Die beiden Fortigate müssen sich als Peers kennen (vgl. Active-Passive Mode, Konfiguration der Peers). Abbildung 7: Peer-Konfiguration auf beiden Peers Auf der Client-Seite (also auf der Fortigate, auf deren Seite die zu optimierende Verbindung gestartet wird) muss nun eine Rule mit Auto-Detect Off und Angabe des gewünschten Peers konfiguriert werden. Die anderen Einstellungen entsprechen der Active-Rule aus der Active-Passive Konfiguration. Seite 9 von 21

10 Abbildung 8: Konfiguration der Peer-Rule auf der Client Seite Auf der Server-Seite muss interessanterweise keine Rule konfiguriert werden. Werden in einer Peer-to-Peer Konfiguration in beide Richtungen Verbindungen aufgebaut, so braucht es auf beiden Seiten eine Peer-to-Peer Rule (Auto-Detect Off ). Konfiguration WebCaching mit Active/Passive- oder PeerToPeer Rule 1. Web Caching in einer Active/Passive Konfiguration Um zusätzlich zum ByteCaching und der Protocol Optimization auch das WebCaching auf einer Active Rule einzuschalten, muss als Protocol HTTP ausgewählt sein und das ByteCaching aktiviert werden. Dann wird das Webcaching automatisch aktiviert. Bei der Passiven Rule muss zusätzlich die Checkbox Enable Web Cache eingeschaltet sein. 2. Web Caching in einer Peer-to-Peer Konfiguration Für die Peer-to-Peer Rule des Initiators gilt gleiches wir für die Active Rule. Da es in diesem Scenario aber keine Passive Rule gibt, muss in der Peer-to-Peer Rule des Initiator die Checkbox Enable Web Cache ausgewählt sein. Konfiguration WebCaching Only Ganz anders liegt der Fall, wenn nur das Webcaching benutzt werden soll. Im Gegensatz zu den vorherigen Beispielen wird für dieses Szenario nur eine Fortigate benötigt. Seite 10 von 21

11 Das WebCaching der Fortigate kann jeweils auf beiden Seiten eingesetzt werden: 1. Als normaler WebCache für die eigenen Clients, welche ins Internet surfen 2. Als reverse WebCache für eingehende Zugriffe auf die internen Webserver 1. WebCache für ausgehende Verbindungen der lokalen Clients Abbildung 9: Netzwerkskizze für herkömmlichen WebCache Konfiguration auf der Fortigate (Clientseite): Abbildung 10: Konfiguration der WebCache Rule Die Definition von Peers ist in diesem Fall nicht notwendig, da die Fortigate das WebCaching allein übernimmt. Es muss lediglich eine WAN Optimization Regel vorhanden sein, die für ausgehenden Traffic auf Port 80 das WebCaching aktiviert. Bei der Adressangabe der Sources ist darauf zu achten, dass die WAN Optimization Rule greift, bevor das Network Address Translation der normalen Firewall Rule greift. D.h. es muss an dieser Stelle der interne, private Adressrange angegeben werden. Seite 11 von 21

12 2. Reverse WebCache für eingehende Verbindungen auf die lokalen Webserver Andersherum kann das WebCaching der Fortigate auch zur Entlastung für die eigenen Webserver verwendet werden. D.h. eingehende Anfragen von externen Clients auf die eigenen Webserver werden vom WebCache der Fortigate anstelle der WebServer direkt beantwortet. Konfiguration auf der Fortigate (Serverseite): Abbildung 11: Netzwerkskizze für reverse WebCache Auch hier ist die Definition von Peers nicht notwendig. Wieder ist nur eine WAN Optimization Regel wichtig, welche für eingehenden Traffic auf Port 80 das WebCaching aktiviert. Bei der Adressangabe der Destination ist nun jedoch zu beachten, dass die WAN Optimization Rule erst nach dem NATting einer evtl. virtuellen IP greift. D.h. es muss auch dieser Stelle die interne Adresse des oder der Server angegeben werden. Abbildung 12: Konfiguration der reverse WebCache Rule Die unterschiedliche Reihenfolge von NAT und WAN Optimization für ein- und ausgehenden Traffic mag auf den ersten Blick sicherlich verwirrend sein mit folgender Sichtweise wird es aber wieder etwas logischer: die Firewall Regeln sitzen sehr weit aussen, das WAN Optimization liegt weiter innen auf der Fortigate. Je nach dem aus welcher Richtung der Traffic kommt (von aussen oder von innen), wird also erst die Firewall-Regel mit dem NAT oder erst das WAN Optimization durchlaufen. Seite 12 von 21

13 zwischen Fortigates und FortiClient Der FortiClient ab der Version v4.0 unterstützt ebenfalls das WAN Optimization. Es wird insbesondere die Protokolloptimierung, das Byte- und das WebCaching unterstützt. Abbildung 13: Netzwerkskizze für nachfolgendes Beispiel Hierbei ist es egal, ob die FortiClients die Verbindung, die WAN optimiert werden soll, direkt oder über ein VPN aufbauen. Beide Varianten können vom WAN Optimization der Fortigate behandelt werden. Konfiguration auf der Fortigate: Prinzipiell wird das WAN Optimization als Active-/Passive-Rule konfiguriert. Die Fortigate ist in diesem Fall die passive Seite. D.h. auf der Fortigate müssen die passive Rule und die FortiClients als Peers konfiguriert werden. Allerdings ist die Konfiguration von dedizierten Peers in den seltensten Situationen möglich, da die FortiClients normalerweise keine fixe IP Adresse haben. In dieser Situation kann man sich aber mit den Authentication Groups behelfen und hier die von den FortiClients verwendete Authentifizierung verwenden. Seite 13 von 21

14 Abbildung 14: Konfiguration der Authentication Group für Forticlients Wichtig ist, dass die Authentication Group für die FortiClients exakt den Namen auth-fc haben müssen und über das Zertifikat Fortinet_Firmware authentifizert werden. Alle anderen Namen funktionieren nicht. Abbildung 15: Konfiguration der Passive Rules Die Source Adresse beschriebt in diesem Fall die Absenderadresse der FortiClients. Wird die Verbindung vom Client ohne VPN aufgebaut, so wird hier wahrscheinlich konfiguriert werden müssen (sofern die FortiClients keine fixe IP Adresse besitzen). Wird die Verbindung über einen IPSec Tunnel aufgebaut und die Clients bekommen innerhalb des Tunnels eine virtuelle IP Adresse zugewiesen, kann diese Adresse als Source Adresse verwendet werden. Seite 14 von 21

15 Als Destination Adresse wird auf jeden Fall der interne Adressbereich der Server angegeben. Also die Adressen, die über einen IPSec Tunnel vom Client angesprochen werden. Falls kein IPSec Tunnel verwendet wird der Zugriff also direkt übers Internet erfolgt wird evtl. von der Firewall-Regel der Fortigate ein Destination NAT über eine virtual IP durchgefüht. Da die WAN Opt Rule aber erst nach der Firewall-Rule zum Einsatz kommt, muss als Destination Adresse der WAN Opt Rule ebenfalls die interne Adresse auf die durch die VIP weiter geleitet wurde verwendet werden. Konfiguration auf dem FortiClient: Die Konfiguration hier ist recht einfach. Ueber das Menu General WAN Optimization muss die Funktion über die Checkbox Enable WAN Optimization eingeschaltet werden und dann die Protokolle, für die Protokolloptimierung durchgeführt werden soll, aktiviert werden. Evtl. kann noch der maximale Disk Cache vergrössert werden. Abbildung 16: Aktivierung des WAN Optimization auf dem FortiClient Seite 15 von 21

16 Überwachung der WAN Optimization Über den Menupunkt Monitor vom WebGUI kann man sehen, wie wirksam die WAN Optimierung funktioniert. Die Traffic Summary gibt an, zu welchem Anteil welches Protokoll optimiert wird und wie hoch die Reduction Rate für jedes Protokoll war. Dabei gilt: je höher die Reduction Rate, desto weniger Traffic musste übers WAN geschickt werden. In der Bandwidth Optimization ist angegeben, wie viel Traffic zu einem Zeitpunkt über das WAN Interface (heller Balken) und wie viel Traffic gleichzeitig über ein internes Interface (dunkler Balken) gesendet wurde. Dieses zeigt insbesondere die Auswirkungen des Byte Cachings an. Abbildung 17: WAN Optimization Monitor In der Abbildung ist ein Beispiel für die zweimalige Übertragung der gleichen Datei mit Byte Caching zu sehen. Zunächst wird eine neue für das Byte Caching unbekannte - Datei gesendet (14:56 14:57 Uhr). Die Datei ist ca. 56 MB gross und für die Übertragung werden ca 1.5 Minuten gebraucht. Zu dem ist ersichtlich, dass für die Uebertragung der Datei etwas mehr Daten über das WAN als über das interne Interface geschickt werden. Der Grund liegt darin, dass die sendende Fortigate zunächst den Hashwert eines Segmentes schickt, dann aber nochmal das Segment an sich schicken muss, da die empfangende Fortigate die Datei noch nicht kennt. Bei der zweiten Übertragung (14:58) sieht man nur noch den Traffic auf dem internen Interface. Dieses ist wieder die originale Datei, die zur Fortigate geschickt wird. Die Fortigate braucht auf dem WAN Interface jetzt aber nur noch die Hashes zu schicken, welche wesentlich kleiner sind. Neben der massiven Datenreduktion auf dem WAN Interface ist ebenfalls ersichtlich, dass die Übertragungsdauer stark gesunken ist (<30 Sekunden). Seite 16 von 21

17 Um zu kontrollieren, ob eine bestimmte Session über das WAN Optimization läuft, ist die Session Liste des CLI zu empfehlen. Zunächst sollte ein Filter für die Sesson Liste gesetzt werden, danach kann die gewünschte Session angezeigt werden: HeadQuarter # diag sys session filter dport 445 HeadQuarter # diag sys session list session info: proto=6 proto_state=11 duration=16 expire=3594 timeout=3600 flags= sockflag= sockport=7800 av_idx=0 use=4 origin-shaper= reply-shaper= per_ip_shaper= ha_id=0 hakey=357 policy_dir=0 tunnel=/ state=redir local may_dirty nlb rem statistic(bytes/packets/allow_err): org=39993/513/1 reply=134081/246/1 tuples=2 orgin->sink: org pre->post, reply pre->post dev=9->3/3->9 gwy= / hook=pre dir=org act=noop :3353-> :445( :0) hook=post dir=reply act=noop :445-> :3353( :0) pos/(before,after) 0/(0,0), 0/(0,0) misc=0 policy_id=2 auth_info=0 chk_client_info=0 vd=0 serial=00000a70 tos=ff/ff imp2p=0 app=0 dd_type=6 dd_rule_id=1 total session 1 Anmerkung: Wichtig ist, dass die Session erst dann aufgebaut werden darf, wenn alle WAN Optimization Konfigurationen abgeschlossen wurden. Wird erst die Session aufgebaut und dann eine entsprechende WAN Optimization Regel konfiguriert, so hat das auf die bestehende Session keinen Einfluss mehr (mit dem CLI Befehl: diag sys session clear können alle existierenden Sessions gelöscht werden, die auf dem aktuelle Filter passen (Vorsicht: falls kein Filter gesetzt ist, werden mit diesem Befehl alle Sessions gelöscht!)) Die letzte Zeile jeder Session zeigt mit dd_rule_id an, welche WAN Optimization Regel verwendet wird. dd_rule_id=0 bedeutet, dass kein WAN Optimization auf dieser Session durchgeführt wird. Seite 17 von 21

18 Anhang Grösse der internen Festplatten Modell FG51B FG82C FG111C FG311B ASM-S08 (storage module AMC) FSM-064 (storage module FSM) Festplattengrösse 32 GB Solid State Drive 1 TB drive installed; 3 bays available for additional 1 TB drives 64 GB Solid State Drive 64 GB Solid State Drive 80GB HDD 64 GB Solid State Drive WAN Optimization Test mit Durchsatzzahlen In der nachfolgenden Tabelle werden Messungen von Durchsatzzahlen mit und ohne WAN Optimization dargestellt. Es ist sehr deutlich zu sehen, welche Performancesteigerungen Protokoll Optimization und vor allem das Byte Caching liefern. Allerdings muss beim Byte Caching bedacht werden, dass dieses nur effizient arbeitet, wenn die Datensegmente auch wirklich gleich bleiben. Wird z.b. bei einer normalen unformartierten Textdatei gleich zu Beginn nur ein Zeichen eingefügt, so verschiebt sich die gesamte Datei um ein oder zwei Byte. Damit verändern sich alle Datensegmente der Datei. Wird z.b. Microsoft Office Datei auch nur ein einzelnes Zeichen ausgetauscht, so hat es dennoch zur Folge das Metadaten der Datei verändert werden und sich auch damit sämtliche Datensegmente verändern können. In diesen Fällen hat das ByteCaching keinen positiven Effekt mehr. Diese Effekte sind ebenfalls in der Tabelle nachzuvollziehen. Seite 18 von 21

19 WAN Optimization Test Headquarter Branch Office Internet Standleitung, 10MB, symm. ADSL, 1MB download, asym. Test ohne WAN Opt HQ --> BO, [sec] HQ --> BO BO --> HQ Conclusion of this test: PDF, 4 MB Direction HQ-->BO is much faster than BO-->HQ PDF, 6 MB because of different up- and download rates at BO. DOC, 4 MB DOC, 6 MB PPT, 5 MB PPT, 10 MB Test mit WAN Opt, Copy HQ --> BO, [sec] 1st copy 2nd copy 3rd copy Conclusion of this test: (CIFS Opt + Byte Cache) PDF, 4 MB First copy is faster than copy without WAN opt --> PDF, 6 MB Protocol optimization on CIFS takes effect. Further DOC, 4 MB copies are much, much faster --> Byte caching takes effect. DOC, 6 MB PPT, 5 MB PPT, 10 MB Test mit WAN Opt, Open HQ --> BO, [sec] 1st opening 2nd opening 3rd opening Conclusion of this test: (Files in HQ, Open from BO) original No matter where and how the file is changed (begin, (RTF-File, 4.5 MB) last char changed end, insert), every change requires a "re-learning" of first char changed the file. A byte comparsion of the original and changed files shows that there is not only one difference (the first char inserted changed char) but a lot of changes in some kind of copy of original meta information. "Renaming" of a file doesn't alter the content of this file.

20 4th Conclusion of this test: Test mit WAN Opt, Open HQ --> BO, [sec] 1st opening 2nd opening 3rd opening opening (Files in HQ, Open from BO) original Within a normal text file (without any formatting or meta information) a change of one char results in (TXT-File, 3.5 MB) last char changed only this one change. So improvements are visible first char changed to the files where only one char is changed. If a char first char inserted is inserted at the beginning the whole file has to be copy of original relearned. Test mit WAN Opt, Saving BO --> HQ, [sec] 1st saving 2nd saving 3rd saving Conclusion of this test: (Save from BO to HQ) original Saving of the text file works in the same way as the opening test with the text file. Changing of only one (TXT-File, 3.5 MB) last char changed character doesn't have a big effect. Only inserting a first char changed char at the beginning needs a "re-learning". It's first char inserted obvious in this last file saving that traffic from BO to HQ is much more slowly) than in the other direction (because of the small upload in the BO) Seite 20 von 21

21