Ein weiteres Release ist da – mit vielen News
Nachdem wir im April das letzte SD-WAN Release mit 20.1 / 17.2.1 erhalten haben, ist nun nach den Sommerferien – etwas verspätet – das “Juli”-Release in Form der Version 20.3 / 17.3 erschienen. Auch bei diesem Release gibt es so viele News, dass ich nur die in meinen Augen wichtigsten in diesem Blog beschreiben möchte. Mehr Infos gibt es wie immer in den entsprechenden Release Notes oder Configuration Guides.
Service-Side NAT
Neu kann auch auf cEdge ein Service-Side NAT erstellt werden, um Branches mit overlapping IP-Ranges via NAT erreichbar zu machen. Bis dato war dies den vEdge Geräten vorbehalten, nun ist das Feature mit dem Juli-Release auch auf cEdge verfügbar geworden.
Enhanced Tracker support
In SD-WAN Umgebungen sind viele Parameter im Spiel, so sollten die verschiedenen Services wie Transport/Underlay Verbindungen, Routing Informationen oder Public Cloud Services stetig erreichbar sein und im Falle eines Ausfalles die SD-WAN Lösung entsprechend reagieren können. Dazu können Tracker eingesetzt werden, welche die oben genannten Aspekte permanent überwachen und bei einem Problem eine entsprechende Aktion triggern. Mit 20.3 / 17.3 sind diese Tracker weiter ausgebaut worden und nun können diverse Zustände via den Trackern entsprechend überwacht werden.
Ein weiteres Feature, auf das viele Kunden gewartet haben, ist nun auch da:
Custom App support
Cisco Viptela SD-WAN unterstützt auf den cEdge die NBAR2 Library, um Applikationen erkennen zu können. Diese Erkennung kann anschliessend in weiteren Policies verwendet werden, um beispielsweise ein AAR (Application aware Routing) durchzuführen, oder ein SLA basierendes Verhalten zu definieren – genau diese Intelligenz sind die Stärken einer SD-WAN Lösung. Setzte jedoch der Kunde eigens entwickelte oder seltene Applikationen ein, konnte es vorkommen, dass die NBAR Library diese nicht erkannte und somit die Applikation nur noch via QoS erfasst werden konnte, denn die App-Library konnte kundenseitig nicht angepasst werden. Seit 20.3 / 17.3 ist diese Möglichkeit nun vorhanden und diese Lücke ebenfalls gefüllt.
Da vEdge in Bezug auf die Applikations-Erkennung eine andere Methodik anwendet, ist diese Funktion nur auf cEdge verfügbar.
TrustSec / SDA Integration (Phase-1)
Die Cisco TrustSec oder auch SDA Architektur kennt ein zusätzliches Flag, das einem Paket mitgegeben werden kann, das SGT (secure oder scalable group tag). Mittels diesem SGT Identifier werden Pakete auf ihrer Reise durch das Netzwerk mit einem Tag gekennzeichnet und können somit im ganzen Netzwerk klar einem System oder einer Gruppe zugeordnet werden. Mit Hilfe dieser Zusatz-Information ist es irrelevant, welche IP-Adresse ein System, Benutzer oder Gruppe hat, denn das entsprechende SGT definiert die Identität und damit ist das Paket von der IP-Adresse entkoppelt. Dies stellt eine sehr starke Vereinfachung dar, wenn im Rahmen von ZeroTrust Filtering, Policies oder auch nur schon Zuordnungen von Systemen durchgesetzt werden müssen, denn man kann sich auf SGT Tags beziehen und nicht mehr auf MAC oder IP-Adressen.
SD-WAN unterstützte bis dato den Transport dieser SGT nicht und der einzige Weg war, die Tags via SXP als Transport-Protokoll mittels einer separaten TCP Session von LAN Geräten zu übertragen, was einerseits nicht so effizient war und andererseits diese Informationen für SD-WAN nicht mehr transparent machte.
Mit 20.3 / 17.3 ist der Transport von Inline-Tags nun unterstützt und somit als Phase-1 auch eine weitere Integration der TrustSec, resp. SDA Micro-Segmentation Information möglich.
Dynamic on-demand Tunnels
Im Gegensatz zu DMVPN war ursprünglich bei der Viptela Architektur von SD-WAN eine Verwendung von dynamischen Tunnels nicht vorgesehen, denn die Viptela Lösung unterstützt alle Varianten von Full-Mesh bis hin zu Point-2-Point Topologien. Jedoch ist der Bedarf an Full-Mesh Verbindungen immer mehr angestiegen und somit auch die Frage nach der Skalierung, vor allem beim Einsatz von kleineren Routern.
Die Verwendung von dynamischen Tunnels entschärft dieses Problem und somit bietet Viptela SD-WAN ab 20.3 / 17.3 die Unterstützung von dynamischen Tunnels, analog zu DMVPN.
Verbesserungen im IaaS Cloud Umfeld
Der Cloud Dienst von AWS kennt das Konzept des Transit Gateways, das als zentraler Eintrittspunkt in eine virtuelle AWS IaaS Kundenumgebung genutzt werden kann. Bis anhin unterstützte die Viptela Lösung diese Möglichkeit nicht, was zu dezentralen Eintrittspunkten und damit zu höheren Cloud Kosten führen konnte. Seit 20.3 / 17.3 ist das AWS Transit Gateway Design unterstützt.
Route Leaking
Immer wieder kam seitens Kunde die Design-Frage auf, ob Traffic vom Underlay ins Overlay, resp. in einen LAN Bereich einer Site geleitet werden kann. Die Antwort war immer Nein, denn im Design der Viptela Lösung kam diese Möglichkeit wegen Sicherheits-Überlegungen nicht vor, die Software Implementierung liess keinen Datenverkehr zwischen VPN0 (Transport-Seite / WAN) in ein VPNx (Service-Seite / LAN) nicht zu. Diese Software-Abschottung ist einerseits korrekt, um die Service-Seite in jedem Fall vom WAN zu schützen, andererseits führt es in einigen Fällen auch zu Umgehungslösungen, die speziell gebaut werden müssen.
Beispiele sind Migratios-Szenarien oder fixe Services, die nur via Underlay zu erreichen sind. Mit dem neuen Release sind nun Router Leaking-Szenarien zwischen WAN und LAN möglich – aber natürlich sollten solche Implementierungen nur gemacht werden, wenn sie anders nur schwer zu lösen oder nur temporär eingesetzt sind.
Adaptive Quality of Service
Ein sehr spannendes Feature ist das Adaptive QoS, denn dies löst eine Problematik, die ansonsten nur schwer und aufwändig zu bewältigen ist via der Automatisierung von SD-WAN.
Wie soll sich die Lösung verhalten, wenn an den Aussenstandorten schmale Leitungen mit wenig Bandbreite, am zentralen Standort jedoch ein hochwertiger Anschluss mit viel Bandbreite eingesetzt wird? Dies ist eigentlich der Normalfall, denn am Hauptstandort kommen typischerweise die Verbindungen zusammen und dies ist in den meisten Fällen auch der Standort mit der höchsten Mitarbeiterzahl. Dies resultiert jedoch auch in folgendem Problem; nehmen wir einen Aussenstandort mit einer symmetrischen 100Mbps Leitung und der Hauptstandort mit 1Gbps an. Der Hauptstandort ist gegenüber dem Aussenstandort somit 10:1 überdimensioniert.
Sendet nun der Aussenstandort mit voller Bandbreite an den Hauptstandort, so kommen dort 100Mbps an – kein Problem für die 1Gbps Leitung. Problematisch wird es jedoch, wenn die Antworten zurückgesendet werden, der Hauptstandort sendet mit 1Gbps, der Aussenstandort wird mit 10:1 überbucht und muss die Pakete verwerfen. Abhilfe schafft hier eigentlich nur ein ausgefeilter QoS-Ansatz, der jedoch in Abhängigkeit der Bandbreiten geschaffen werden müsste und somit sehr komplex wird, auch da die Bandbreiten in grossen Kunden-Netzwerken permanent angepasst und verändert werden.
Schön wäre es, wenn die Lösung diese Problematik selbständig übernehmen könnte, denn der Aussenstandort könnte ja dem Hauptstandort seine Bandbreite mitteilen und der entsprechend darauf Rücksicht nehmen. Mit dem aktuellen Release ist dies soweit, denn das Adaptive QoS übernimmt genau diese Aufgabe.
Es gibt noch viele weitere Verbesserungen und neue Funktionen mit dem neuen Release, jedoch sprengt dies den Rahmen des Blogs. Hier verweise ich auf die schon zu Beginn erwähnten Dokumentationen wie Release Notes oder Configuration Guides.
Die Viptela SD-WAN Lösung entwickelt sich stetig weiter und zeigt immer mehr die Möglichkeiten, die in einer Software basierenden Lösung stecken, so soll es sein! Weiterhin viel Spass mit SD-WAN.
Authors