Mai 2012: NetScaler Admin Training in Hannover

In Kooperation mit dem Citrix Authorized Learning Center „CALC“ ADN Distribution GmbH.:

Basic Administration NetScaler 9.3 (Vorbereitungskurs zur Zertifizierung als CCA NetScaler)

In diesem Kurs werden Ihnen Grundkenntnisse der Administration und der Konfiguration des NetScalers vermittelt. Ebenfalls werden die aktuellen Hard- und Software Updates der Version 9.3 sowie die virtuelle NetScaler Appliance VPX besprochen.

Zielgruppe
Das Citrix NetScaler Training – Basic Administration for Citrix NetScaler 9.3 richtet sich an Systemadministratoren, Systemingenieure, Systemarchitekten oder Netzwerkspezialisten.

Seminarziele
Der Kurs macht Sie auf effektive und praxisnahe Weise mit der Konfiguration und Administration von Citrix NetScaler 9.3 vertraut. Es vermittelt Ihnen die NetScaler Eigenschaften wie Load Balancing, SSL Offload sowie das Erstellen von klassischen und erweiterten Richtlinien, Expressions, Rate Limiting und Applikationstemplates. Nach dem Seminar sind Sie in der Lage, Einsatzgebiete für NetScaler 9.3 richtig einzuschätzen, NetScaler eigene IP Adressen zu erkennen und VLANs (virtual local area networks), RNAT (reverse network address translation) und Zugriffsberechtigungslisten (ACLs) zu konfigurieren.

Vorkenntnisse
Optimale Voraussetzung für eine erfolgreiche Teilnahme sind gute Kenntnisse von TCP/IP und HTTP-Protokollen sowie des OSI-Modells. Weiterhin sollten Sie über Erfahrungen mit Netzwerkkomponenten und Systemadministrationskonzepten inkl. Logging, Softwareupgradeverfahren und Hochverfügbarkeitsszenarien verfügen. Basiskenntnisse in Bezug auf DNS, SSL und Kompression, Server Load Balancing und Content Switching sowie Vertrautheit mit Webserver-Software (z.B. IIS, Apache, WebSphere) und Themen wie Netzwerksicherheitsbedrohungen und Absicherungskonzepte (Firewalls usw.) sind ebenfalls von Vorteil.

Wann?
21. bis 25.05.2012
09.00 – 17.00 Uhr

Wo?
Michael Wessel
Informationstechnologie GmbH
Krausenstraße 50
30171 Hannover

Kosten?
2595,- €* inkl. Tagesverpflegung, original Citrix Learning Courseware und Zugriff auf Citrix Learning Labs
*zzgl. MwSt.

Bei Interesse kontaktieren Sie Frau Wegrich unter 0511 260 911-44 oder per E-Mail über nw@consulting-lounge.de.

Citrix Whitepaper: NetScaler Integrationsgrundlagen

Über offizielle Citrix Kanäle wurde das Paper schon vor einigen Tagen publiziert, in meiner neuen Version sind noch mal Kleinigkeiten verschönert (Bildunterschriften u.a.). Grundlagen-Lektüre für die Planung, Inbetriebnahme und das Kennenlernen der Basis-Features von Citrix NetScaler:

WP_NetScaler Erste Schritte, Integrationsgrundlagen v1.1

Zu diesen und weiteren Themen sind wir auch auf der CeBIT ansprechbar: Sie finden uns auf dem Virtualisation & Storage Forum in Halle 2 (Stand A40).

NetScaler Training in Hannover

20.02.2012: Basic Administration for Citrix NetScaler 9.2

In diesem Kurs werden Ihnen Grundkenntnisse der Administration und der Konfiguration des NetScalers vermittelt. Ebenfalls werden die aktuellen Hard- und Software Updates der Version 9.2 sowie die virtuelle NetScaler Appliance VPX besprochen.

Zielgruppe
Das Citrix NetScaler Training – Basic Administration for Citrix NetScaler 9.2 richtet sich an Systemadministratoren, Systemingenieure, Systemarchitekten oder Netzwerkspezialisten.

Seminarziele
Der Kurs macht Sie auf effektive und praxisnahe Weise mit der Konfiguration und Administration von Citrix NetScaler 9.2 vertraut. Es vermittelt Ihnen die NetScaler Eigenschaften wie Load Balancing, SSL Offload sowie das Erstellen von klassischen und erweiterten Richtlinien, Expressions, Rate Limiting und Applikationstemplates. Nach dem Seminar sind Sie in der Lage, Einsatzgebiete für NetScaler 9.2 richtig einzuschätzen, NetScaler eigene IP Adressen zu erkennen und VLANs (virtual local area networks), RNAT (reverse network address translation) und Zugriffsberechtigungslisten (ACLs) zu konfigurieren.

Vorkenntnisse
Voraussetzung für eine erfolgreiche Teilnahme sind gute Kenntnisse von TCP/IP und HTTP-Protokollen sowie des OSI-Modells. Weiterhin sollten Sie über Erfahrungen mit Netzwerkkomponenten und Systemadministrationskonzepten inkl. Logging, Softwareupgradeverfahren und Hochverfügbarkeitsszenarien verfügen. Basiskenntnisse in Bezug auf DNS, SSL und Kompression, Server Load Balancing und Content Switching sowie Vertrautheit mit Webserver-Software (z.B. IIS, Apache, WebSphere) und Themen wie Netzwerksicherheitsbedrohungen und Absicherungskonzepte (Firewalls usw.) sind ebenfalls von Vorteil.

Wann?
20. bis 24.02.2012
09.00 – 17.00 Uhr

Wo?
michael-wessel.de
Krausenstraße 50
30171 Hannover

Kosten?
2595,- €* inkl. Tagesverpflegung, original Citrix Learning Courseware und Zugriff auf Citrix Learning Labs
*zzgl. MwSt.

Bei Interesse kontaktieren Sie Frau Wegrich unter 0511 260 911-44 oder per E-Mail über nw@consulting-lounge.de.

In Kooperation mit dem Citrix Authorized Learning Center „CALC“ ADN Distribution GmbH.

Most Certified Citrix Networking Partner

Zwar gibt es keine offizielle Auszeichnung dafür, aber nach unserem Kenntnisstand sind wir mindestens für Deutschland der most committed und vor allem most certified Citrix Networking Partner: Stand heute haben wir 5 (fünf) Citrix Certified Administrators (CCA) für Citrix NetScaler und einen Citrix Certified Instructor 2012 for Networking (CCI, der natürlich auch CCA für NetScaler und Access Gateway Enterprise ist) im Team.

Das musste einfach mal gesagt werden. 😉

NetScaler High Availability

Ein wie selbstverständlich schon genanntes Feature des NetScalers ist der Betrieb in einem Verbund mehrerer Systeme zur Sicherstellung von Hochverfügbarkeit. Durch seine Funktionalität als intelligenter Load Balancer stellt der NetScaler Hochverfügbarkeit für die Backend Services her, die er beliefert, wird damit aber zugleich zum hochkritischen Punkt der Infrastruktur, von dessen Verfügbarkeit zahlreiche zentrale Dienste abhängig sind.

Active/Standby Modus

Die am häufigsten eingesetzte und angebrachte Variante der HA Modus ist Active/Standby. In dieser Betriebsart bilden zwei NetScaler Appliances ein HA Paar, in dem lediglich die NSIPs individuell sind, während alle anderen Adressen „floating“ beim Failover vom Standby System übernommen werden. Konfigurationsänderungen sind nur auf dem aktiven Knoten (Primary) möglich bzw. dauerhaft. Solange beide Systeme in Betrieb sind, werden alle auf dem Primary ausgeführten Kommandos (also alle Konfigurationsänderungen) per „Command Propagation“ auch auf dem Secondary Node ausgeführt. Bei einem Reboot zieht sich das startende Standby System die Konfiguration einmal komplett vom Primary Node (HA Synchronization).

Active/Standby mit INC

Eine Spielart des Active/Standby Modus ist die Independent Network Configuration (INC), die dann erforderlich ist, wenn ein HA Paar auf zwei Standorte verteilt ist, in denen unterschiedliche IP-Netze verwendet werden oder zwischen denen die Layer 2 Verbindung ausfallen könnte oder gar nicht erst existiert. Die INC erlaubt es jedem Knoten im HA Paar, die Backends jederzeit selbst zu überwachen und damit auch ohne Verbindung mit dem HA Partner den Monitor Status zu kennen, da neben der NSIP auch die SNIPs/MIPs individuell und damit jederzeit aktiv sind. Im Unterschied zu einem Deployment mit Global Server Load Balancing (GSLB), das als nächste Abstraktionsstufe der Hochverfügbarkeit gelten kann, handelt es sich aber immer noch um ein HA Paar, das eine gemeinsame Konfiguration synchronisiert.

Befinden sich die Knoten nicht im selben Layer 2 Segment, müssen die VIPs wiederum per Route Health Injection bekannt gemacht werden, d.h. es muss ein dynamisches Routing Protokoll zum Einsatz kommen. Anderenfalls reicht der normale IP Failover mit anschließender Gratuitious ARP (GARP) Bekanntgabe an alle Teilnehmer des Segmentes aus.

NetScaler Pools, Active/Active

Zu einem HA Deployment können auch mehr als zwei NetScaler verbunden werden, wir sprechen dann von NetScaler Pools. Zwar ist auch ein Deployment mit mehr als einem Standby System möglich (Active/Standby/Standby/…), aber in der Praxis sind NetScaler Pools vor allem sinnvoll in Situationen, wo mehr aktive Leistung benötigt wird, als eine einzelne Appliance liefern kann. In Anbetracht der Leistungsmerkmale der MPX Hardware Appliances sind diese Situationen zwar äußerst selten, aber auch dieser Ansatz zur Skalierung kann wünschenswert sein (z.B. sehr hohe Durchsatzanforderung für FIPS-zertifiziertes Deployment). Ein NetScaler Pool mit mehreren aktiven Knoten ist eine Erweiterung eines einfachen Active/Active Paares, um zusätzliche Failover Kapazität (N+1 oder auch N+X) und Leistung.

Bei Active/Active Deployments besteht kein HA Paar im Sinne von gemeinsamer Konfiguration oder gemeinsamen IP Adressen, alle NetScaler laufen standalone. Die Zuordnung von VIPs zu Systemen erfolgt mit Hilfe des Virtual Router Redundancy Protocols (VRRP), indem jedem NetScaler für jede VIP eine Priorität zugewiesen wird. Die Systeme regeln dann untereinander, welche VIP zu einem Zeitpunkt auf welchem NetScaler aktiv ist. Dabei wandert gemäß VRRP auch eine Virtual MAC (VMAC), die zu jeder VIP gehört und aus der Virtual Router ID (VRID) gebildet wird, beim Failover mit auf den nächsten NetScaler.

Als weitere Konsequenz aus der Tatsache, dass die Systeme in einem NetScaler Pool keine Synchronisationsmöglichkeit haben, müssen zur Sicherstellung von Session Persistence verbindungslose („stateless“) Methoden eingesetzt werden. Beispiele dafür sind Hash-basierte Persistenz und vor allem Cookie Insert, bei dem der Client seine Persistenz-Informationen praktisch selbst besitzt und mitliefert.

VMACs und Firewall Load Balancing

Bei einem IP Failover wird die neue Heimat einer IP-Adresse durch GARP Pakete bekanntgegeben. Sicherheitskritische Systeme beachten diese Pakete unter Umständen nicht weiter, da ihnen damit auch gefälschte ARP Einträge untergeschoben werden könnten, so dass es zu längeren Unterbrechungen im Falle eines Failovers kommen kann. Hier, wie auch speziell im Sonderfall des Firewall Load Balancing, das in der Regel sowieso auf Layer 2 stattfindet, sind virtuelle MAC Adressen (VMACs) hilfreich. Diese können ebenso zwischen NetScalern wandern wie IP-Adressen, so dass keine Neuzuordnung von IP zu MAC mehr erforderlich ist.

Auslöser für ein Failover

Neben der völligen Unerreichbarkeit des bislang aktiven Partners gibt es weitere Auslöser – oder auch Hinderungsgründe – für ein Failover der Ressourcen auf einen Standby NetScaler. So kann die Erreichbarkeit eines HA Partners abhängig sein von der Verfügbarkeit von Routern, so dass diese ein Entscheidungskriterium dafür sind, ob ein System überhaupt beurteilen kann, ob der Partner oder nur die Verbindung offline ist. Zu diesem Zweck können Route Monitors der HA Konfiguration hinzugefügt werden, die kritische (statische) Routen oder die bloße Existenz bestimmter dynamischer Routen überwachen und bei negativer Verfügbarkeit verhindern, dass dieser Knoten aktiv werden kann.

Weiterhin überwachte Ressourcen sind die Netzwerkschnittstellen eines NetScalers. Standardmäßig werden alle verbundenen Interfaces überwacht und der Verlust des Links an einem Interface führt zum Failover auf den Standby Node. Die schon beschriebene Link Aggregation zur Erhöhung der verfügbaren Bandbreite, durch die auch die Abhängigkeit von einem einzelnen Interface aufgehoben wird, muss für die HA Konfiguration in Form eines Failover Interface Set (FIS) abgebildet werden. Beim Ausfall eines Interfaces in einem FIS findet daher kein Failover statt, solange noch ein Interface des FIS verfügbar und verbunden ist. Alle Schnittstellen, die nicht Teil eines Failover Interface Set sind und auf denen der HA Monitor nicht deaktiviert ist, sind sogenannte Critical Interfaces.

Lastverteilung und Desaster Recovery über verteilte Rechenzentren

Featuring: Global Server Load Balancing (GSLB)

Ein Unternehmen mit hohen Anforderungen an die Verfügbarkeit seiner Services möchte die Anfragen seiner Benutzer über  zwei geografisch getrennte Rechenzentren verteilen. Wie beim Load Balancing innerhalb einer lokalen Serverfarm wird durch den einheitlichen Eingangspunkt – hier in Form eines Hostnamens statt einer IP-Adresse – und die Verteilung auf verfügbare Server neben einer höheren Leistungsfähigkeit gleichzeitig eine höhere Verfügbarkeit erreicht.

Um die Verfügbarkeit auch innerhalb jedes einzelnen Rechenzentrums zu gewährleisten, erfordert dieses Szenario ein HA Paar aus zwei NetScalern je RZ (z.B. in unterschiedlichen Brandschutzzonen).

Die Funktionsweise des GSLB  ist dann wie folgt: Ein Client möchte auf den Service unter „ica.customer.org“ zugreifen und sendet daher eine DNS Anfrage nach diesem Namen. Der autoritative Nameserver für die Zone „customer.org“ hat für diesen Namen einen CNAME Eintrag, der auf „ica.gslb.customer.org“ verweist, sowie eine Subzone „gslb.customer.org“, die an zwei Nameserver delegiert ist. Diese Nameserver sind die ADNS Service VIPs der beiden NetScaler-Paare. Um die Anfrage zu beantworten, stellt der Resolver also wiederum eine DNS Anfrage nach „ica.gslb.customer.org“ an einen der NetScaler. Dieser bestimmt anhand der konfigurierten GSLB Parameter und des Servicestatus die zurück zu liefernde IP-Adresse und nennt diese als Antwort. Der Client bekommt diese IP-Adresse als Antwort auf seine DNS Anfrage und baut seine Verbindung dann zu der durch die NetScaler bestimmten IP auf.

Die Entscheidung, welche IP auf eine bestimmte Anfrage zurückgeliefert wird, basiert auf den eingestellten GSLB Parametern und Methoden (u.a. Round Robin, Least Connection oder Round Trip Time). Zum Austausch der Statusinformationen, die zur Entscheidung erforderlich sind, sowie von Persistenzinformationen nutzen die NetScaler zwischen den verschiedenen Rechenzentren dabei das Metric Exchange Protocol (MEP). Je Site kommt für diese Kommunikation noch eine weitere IP-Adresse ins Spiel, nämlich die GSLB Site IP, die aber ebenso eine bestehende SNIP oder MIP sein kann wie die ADNS Service IP.

Erweiterte Netzwerkfunktionen des Citrix NetScalers

Um die verfügbare Bandbreite zwischen dem NetScaler und anderen Komponenten über die Kapazität eines einzelnen Interfaces hinaus zu erhöhen, können Interfaces zu sogenannten Channels zusammengefasst werden. Diese Link Aggregation genannte Konfiguration kann manuell oder durch das Link Aggregation Control Protocol (LACP) gesteuert erfolgen. Neben der Bandbreite wird damit zugleich auch die Ausfallsicherheit verbessert, da die Verbindung auch bei Ausfall eines Interfaces noch verfügbar ist.

Interfaces, die Teil eines Link Aggregate Channels werden, übernehmen die Parameter des Channels, insbesondere dessen VLAN Konfiguration. VLANs können sowohl Port-basiert (ein Interface in einem VLAN) als auch mit Tagging nach 802.1q (ein Interface in mehreren VLANs) konfiguriert werden.

Routing oder Bridging von VLANs

Unterschiedliche VLANs sind üblicherweise nur durch Layer 3 Router verbunden, d.h. ein System agiert als IP-Router zwischen ihnen. Diese Funktion kann auch der Citrix NetScaler wahrnehmen, indem je ein VLAN mit einem IP-Subnetz assoziiert und der Layer 3 Mode aktiviert wird.

Bei aktiviertem Layer 3 Mode führt der NetScaler standardmäßig IP-Forwarding zwischen allen ihm bekannten Netzen aus. Um dieses Routing einzuschränken und nur zwischen definierten Netzen durchzuführen, werden IP-Subnetze an sogenannte Bridge Groups gebunden. Dann werden Pakete nur noch in VLANs (Subnetze) weitergeleitet, die zur selben Bridge Group gehören.

Mit Hilfe des NetScalers können mehrere VLANs jedoch auch auf Layer 2 zu einer gemeinsamen Broadcast Domain verbunden werden. Sollen zwei oder mehr VLANs zusammengelegt werden, müsste normalerweise auf allen beteiligten Geräten in allen Domains die VLAN Konfiguration geändert werden. Stattdessen können auf dem NetScaler eine Bridge Group angelegt und die zu verbindenden VLANs dieser Bridge Group zugeordnet werden. Wird dann der Layer 2 Mode aktiviert, leitet der NetScaler Broadcast Pakete aus einem VLAN an alle VLANs in der selben Bridge Group weiter und vermittelt auch Unicast Pakete durch das Nachschlagen aller von ihm in der entsprechenden Bridge Table verzeichneten MAC Adressen.

Erweitertes Routing

Neben dem statischen Routing zwischen Netzen, an die der NetScaler direkt angebunden ist (durch SNIPs) oder die er über statische Routingeinträge kennt, unterstützt er auch dynamische Routingprotokolle wie RIP (v2 und ng), OSPF (v2 und v3) und BGP. Die Teilnahme an diesen Prozessen dient hauptsächlich dazu, an umliegende Router Informationen über identische Virtual Server weiterzugeben (Route Advertising), die zum Beispiel auf mehrere alleinstehende NetScaler verteilt sind. Auf diese Art können Router dann dynamisch Traffic zwischen diesen Virtual Servern verteilen (Equal Cost Multipath, ECMP).

In einem HA Paar wird die Routingtabelle des primären Knotens auf den sekundären gespiegelt, so dass beim Failover keine Unterbrechung des Routings auftritt. Damit auch keine Verbindungsverluste auftreten, weil der vorgelagerte Router noch Traffic an den soeben ausgefallenen Knoten sendet, meldet der verbleibende NetScaler dem Router neue Routingeinträge mit leicht niedrigerer Metrik als die des ausgefallenen Systems (Route Health Injection).

Auch der NetScaler selbst erkennt ECMP, sobald er für ein Ziel mehrere gleichwertige Routen konfiguriert oder gelernt hat, und verteilt Verbindungen mittels eines Hashes über Quell- und Ziel-IP auf die verfügbaren Verbindungen.

Eine weitere Möglichkeit, das Routingverhalten zu bestimmen, sind Policy Based Routes (PBRs). Mit PBRs kann der NetScaler den Next Hop für ein Paket abhängig von verschiedenen Merkmalen wie Quell-/Ziel-IP, Quell-MAC, Ports, Protokoll oder auch VLAN bestimmen. Das Ziel einer PBR kann auch ein Link Load Balancing (LLB) Virtual Server sein, der wiederum auf mehrere Next Hops zurückgreifen kann, so dass beim Ausfall des bevorzugten Routers als Next Hop auf weitere umgeleitet werden kann.

MAC Based Forwarding

Vor der Konfiguration der Netzwerkparameter des NetScalers sollte geklärt werden, ob die Installation den MAC Based Forwarding Modus (MBF) nutzen kann oder muss. In dieser Betriebsart merkt sich der NetScaler für jedes eingehende Paket, von welcher Absender-MAC dieses angekommen ist. Dazugehörige Antwortpakete sendet er wiederum an diese MAC adressiert zurück – unabhängig von etwaigen Routingentscheidungen auf höheren Schichten.

Auf diese Art erspart sich der NetScaler nicht nur das Nachschlagen in seinen Routing- und ARP-Tabellen, sondern er verhindert auch das Entstehen von asymmetrischen Routen. Das ist besonders wichtig, wenn umliegende Systeme statusabhängig agieren, das heißt Pakete nur verarbeiten, die zu einer bekannten, etablierten Verbindung gehören. Typischerweise trifft das für Firewalls zu. Aber auch die Anbindung eines Admin-Netzes per VPN, in dem Adressen auf ein Zwischennetz umgesetzt werden, kann den MBF Modus erfordern, da dem NetScaler dieses Zwischennetz nicht bekannt ist und kein Gateway darin zur Verfügung steht, das Detault Gateway aber ins Internet führt und daher kein Rückweg in das Admin-Netz existiert.

SSL Renegotiation

Vor kurzem wurden Tools veröffentlich, welche mit Hilfe von clientseitiger SSL Renegotiation versuchen, Webserver so stark unter Last zu setzen, dass diese nicht mehr auf Anfragen reagieren können und somit die Seiten für den Zeitraum des Angriffs nicht zur Verfügung stehen (Denial of Service). Abhilfe können hier Loadbalancer wie der Citrix NetScaler schaffen, welcher auf eine effiziente Verarbeitung von SSL-Verschlüsselungen ausgelegt und als Hardware Appliance sogar mit SSL-Beschleuniger-Chips (Cavium) ausgestattet ist.

Darüber hinaus besteht bei vielen Webservern die Möglichkeit die clientseitige SSL Renegotiation zu deaktivieren. Standardmäßig ist dies z.B. bei neueren Versionen des Apache Webservers der Fall.

Steht zwischen Client und Webserver ein Loadbalancer, entsteht die Rechenlast im Normalfall nicht auf dem Backend sondern auf den davor geschalteten Loadbalancern. Um zu verhindern, dass es nun zu einer erhöhten Last auf den NetScalern kommt, besteht hier ebenfalls die Möglichkeit die clientseitige SSL Renegotiation zu deaktvieren:

Die Konfiguration erfolgt in der GUI über die Haupseite SSL -> „Change advanced SSL settings“ -> „Deny SSL Renegotiation“.

IP-Adressen des NetScalers

Der NetScaler hat verschiedene Arten von IP-Adressen für unterschiedliche Aufgaben. Die erste Adresse ist die NSIP (NetScaler IP), die als Management IP immer statisch existieren muss. In einem High Availability Paar aus zwei NetScalern ist die NSIP die einzige fixe IP, die jedes einzelne System individuell besitzt. Über diese Adresse wird der NetScaler administriert und von ihr gehen administrative Verbindungen wie DNS Requests, NTP Zeitsynchronisation, Authentifizierungsanfragen und die HA Synchronisation aus.

Bei der Erstinstallation muss weiterhin mindestens eine MIP (Mapped IP) oder eine SNIP (Subnet IP) konfiguriert werden, die als Ausgangspunkt der Kommunikation zu den Backend Servern verwendet wird. Per Default verwendet der NetScaler eine SNIP, sofern verfügbar, oder fällt sonst auf die MIP zurück („Default SNIP“). Es sollte in jedem IP-Netz, in das der NetScaler direkt kommunizieren kann oder soll, eine SNIP angelegt werden, die für diese Verbindungen genutzt werden kann. Der Weg in andere Netze wird über die Routingtabelle gefunden.

Der Dritte Typ von IP-Adressen sind die VIPs (Virtual IPs), die den Clients als Gegenstelle zur Verfügung stehen. Eine VIP wird typischerweise durch das Anlegen eines Virtual Servers erzeugt, der unter dieser IP ansprechbar ist.

Clients verbinden sich also zu VIPs, wo der NetScaler die Verbindung terminiert. Dann baut er eine eigene Verbindung zu dem Backend Service auf, ausgehend von der entsprechenden SNIP (Default: USNIP Modus) oder MIP, über die er die Client-Anfrage weiterleitet. Sollen die Server stattdessen die Client IP selbst als Quelle der Verbindung sehen, muss der USIP Modus (Use Source IP) aktiviert werden, was sowohl global als auch pro Virtual Server möglich ist.

Bei Verwendung des USIP Modus ist zu bedenken, dass die Antwortpakete der Server direkt an die Client IP adressiert werden, was unter Umständen den NetScaler umgeht, wenn Client und Server sich im selben Subnetz befinden oder der Server eine andere Route in das Client Netz hat als über den NetScaler (asymmetrisches Routing).

Administrative Verbindungen auf SNIP verlagern

Da der NetScaler im Normalfall Verbindungen zu Servern sowohl von seiner NSIP (administrativ) als auch einer oder mehrerer SNIPs/MIPs aufbaut, tauchen in ggf. erforderlichen Firewall Policies unterschiedliche Quelladressen für ein und dasselbe System auf. Um das zu vereinfachen, kann der Administrator dafür sorgen, dass auch administrative Verbindungen wie etwa DNS und LDAP (Authentifizierung) von einer SNIP ausgehen. Dazu werden für alle betroffenen Dienste Load Balancing VServer auf dem NetScaler angelegt, die die eigentlich zu adressierenden Server als load balanced Services ansprechen. Diese Backend Kommunikation geht dann von der entsprechenden SNIP aus, von der auch die sonstigen Verbindungen in das entsprechende Netz initiiert werden.

IP-Adressen im HA Modus

In einem HA Paar ist es sinnvoll, den administrativen Zugriff auf einer SNIP oder MIP zu aktivieren. Da alle Adressen abgesehen von der NSIP im HA Paar „floating“, d.h. immer auf dem primären NetScaler aktiv sind, erreicht man darüber immer das System, auf dem die Konfiguration geändert werden kann.

Sind die an einem HA Setup beteiligten Systeme in unterschiedlichen Subnetzen untergebracht, muss der INC Modus (Independent Networking Configuration) aktiviert werden. Mit INC ist es möglich (und erforderlich), dass die NetScaler eines HA Paares nicht nur unterschiedliche NSIPs, sondern auch individuelle MIPs und SNIPs besitzen. Die VIPs können identisch sein, jedoch unterscheiden sich die IP-Adressen für die Backend Kommunikation entsprechend der unterschiedlichen Subnetze.