ExpressRoute - Für und Wider

Ja, ich habe schon Kunden bei der Einführung von ExpressRoute betreut und nicht immer werden die Erwartungen erfüllt. Dabei ist ExpressRoute gar nicht mal das Problem, sondern es wurde vorab nicht genug beschrieben was ExpressRoute leisten kann. Viel schlimmer ist aber gewesen, dass die Einschränkungen und Nachteile nicht gesehen werden und vor allem gar nicht klar ist, welche Datenvolumen und Lasten zu erwarten sind.

Warum ExpressRoute?

Fangen wir wie jeder Verkäufer erst mal mit den Vorteilen an. Wer heute Office 365 oder Azure-Dienste "über das Internet" nutzt, lebt mit der latenten Gefahr, dass eben diese Anbindung mit SLAs nicht wirklich abzusichern ist. Das SLA bezieht sich auf die Möglichkeit, die gewünschte bzw. geforderte Datenmenge mit einer ausreichend guten Qualität zu übertragen. Auch ein "gestörter" Internet-Zugang durch eine DoS-Attacke von außen oder Überlastung durch interne Clients ist eine Einschränkung des SLAs hinsichtlich Office 365 und Azure. Das Internet ist kein "privates Netzwerk" und wenn ihre Clients über eine öffentliche Adresse sich zu Office 365 verbinden, dann könne Sie auch gestört werden, da diese Adresse und damit zumindest das letzte Stück vom Provider zu ihren für jeden guten und bösen Teilnehmer.

Was kann ExpressRoute?

ExpressRoute ist eine private Leitung von ihren Standorten zu Office 365/Azure. Sie als Kunde lassen also eine Leitung zu den Zugangspunkten von Microsoft legen oder schalten, kaufen bei Microsoft dann die Peering-Leistung (Preise abhängig von der Bandbreite) und konfigurieren bei sich entsprechende Router, BGP-Einstellungen und Leitwege, Proxy-Server und Firewalls, um Zugriffe ihrer Clients optimal zu Office 365 und Azure zu leiten. ExpressRoute liefert:

  • Vorhersehbare Performance
    Die Bandbreite, die Sie bei Microsoft kaufen und über von ihnen beauftragte WAN-Leitungen bis zu ihrem privaten Eingangstor zur Verfügung steht, ist exklusiv für ihre Daten zu Office 365/Azure verfügbar. Über diese Leitung geht kein Internet-Verkehr und auch sonst keine fremden Daten sondern nur Daten zwischen ihrem privaten Azure-System und Daten zu Office 365 und beliebigen "Azure Public"-Diensten.
    Dennoch ist eine seriöse Planung erforderlich, wenn die Bandbreite kann zwar erhöht aber nicht mehr reduziert werden. Ein Netzwerk Assessment ist Pflicht. Es könnte nämlich sonst passieren, dass die garantierte Performance von ExpressRoute letztlich schlechter ist, als die Performance bei der Nutzung des Internet.
  • Getrennter Verkehr von Office 365/Azure und dem Internet
    Hinsichtlich Office 365 und Azure erreichen Sie natürlich ihr Ziel, dass diese Daten sich nicht die gleiche Leitung teilen, über die andere Anwender Dienste im Internet nutzen. Sie können so schon sicher sein, dass ein Angriff oder Überlast-Situation auf dem Internet-Link ihre Office 365/Azure-Funktion in der Regel nicht stören. Allerdings lässt sich mit QoS und entsprechender Steuerung auch auf einem Internet-Link die Bandbreite auch steuern. Nur ein bösartiges "Fluten" von extern  um damit den eingehenden Verkehr zu behindern, kann nur ihr Provider bekämpfen. Viele Provider machen das. Fragen Sie mal nach.
  • 99.9% SLA
    Microsoft garantiert auf seiner Seite ein SLA hinsichtlich der Erreichbarkeit der Dienste. Dieses SLA enthält natürlich nicht die in ihrer Verantwortung betriebenen Leitung von den Zugangspunkten zu ihrem lokalen Netzwerk und sagt auch nichts über ihr eigenes internes SLA für Router, Switches, Firewalls etc. aus. Ich frage daher im Rahmen eines Vorgesprächs auch immer diese Fakten ab.
  • QoS for Skype for Business
    Auf dem "Internet" gibt es keine Priorisierung der Pakete, zumindest nicht wenn man an die Netzneutralität glaubt. Ich bin aber sicher, dass jeder Provider gewisse Datenströme zumindest überwacht oder sogar schon beschränkt. Denken Sie man die Priorisierung, für die Netflix anscheinend bezahlt oder auch die früher oft gesehene Drosslung von eMule-Verkehr.
    Mit ExpressRoute haben Sie natürlich eine eigene dedizierte Leitung zu Skype for Business Online über die Sie auch Sprache und Konferenzen leiten können. Mit dem entsprechenden Provider können Sie ihre Pakete auch entsprechend kennzeichnen und die Pakete kommen dann auch bevorzugt bei Skype for Business Online an..

Weitere Punkte sind mir aber nicht eingefallen die für ExpressRoute sprechen. Aber diese wenigen Punkte machen es dennoch erforderlich seriöse ein entsprechendes Projekt durchzuführen, denn eine Entscheidung zugunsten von ExpressRoute startet einen längeren Prozess mit mehreren Beteiligten und ist damit auch ein nicht unerheblicher Kostenfaktor.

Was ist Express Route nicht?

Die Argumente für ExpressRoute dürfen nicht darüber hinweg täuschen, dass selbst Microsoft in entsprechenden Vorträgen auch die Einschränkungen deutlich aufzeigt. Und das wird Microsoft nicht deswegen machen, weil Sie ExpressRoute vielleicht nicht verkaufen wollen. Der Grund dürfte eher darin liegen, dass in der Vergangenheit viele Firmen mit ExpressRoute loslegen wollten und danach enttäuscht waren. Daher gibt es aktuell (Nov 2017) sogar einen Prozess, dass der Zugriff auf Office 365 über eine bestehende ExpressRoute-Verbindung erst ein Approval bedarf.

Da muss es ja durchaus Gründe für geben. Hier eine kleine Liste, was ExpressRoute alles nicht kann oder welche Annahmen vielleicht nicht immer stimmen

  • ExpressRoute ist schneller als der Weg über das Internet
    Das kann sein aber muss nicht sein. Es nicht ungewöhnlich dass Firmen heute auch mal Gigabit zum Internet haben. Diese Angabe bedeutet ja nicht nur Bandbreite im Bezug auf Datenmenge pro Zeit sondern ist auch ein Maß für die Laufzeit der Pakete. Über eine 64kbit ISDN-Leitung brauch selbst das einzelne Bit länger um übertragen zu werden. Wenn Sie dann z.B. aus Kostengründe eine 100MBit ExpressRoute-Leitung planen, dann ist das Internet meist sogar schneller. Die Betonung liegt auf "meist" und nicht auf "immer". Prüfen Sie einmal, wie viele Hops und mit wie viel Latenzzeit sie vom MGN - Microsoft Global Network entfernt sind und fragen Sie dann ihren geplanten ExpressRoute Provider zu entsprechenden Daten anderer Kunden, die er sicher schon hat.
  • ExpressRoute ist sicherer als Internet
    ExpressRoute ist keine "bevorzugte" Verbindung zu Microsoft hinsichtlich Absicherung. Alle Office 356 Dienste nutzen ohne Ausnahme SSL/TLS auf allen Verbindungen und auf der Seite von Microsoft sind weiterhin Intrustion Detection, DoS, Security-Checks aktiv. Insofern ist die Verschlüsselung identisch und vielleicht wäre ExpressRoute hier sogar unsicherer, da eine "böse Macht" ja nur den einen Carrier anzapfen und quasi ihre Daten schon vorgefiltert bekommt und diese nicht "irgendwo" aus dem Datenstrom im Internet ausfiltern muss. Mit entsprechenden Möglichkeiten könne man ihnen per gefälschtem Zertifikat.....  Ich denke das ist eine müßige Diskussion. Wer ExpressRoute als "sicherer" bezüglich abhören beschreibt, hat etwas missverstanden.
  • ExpressRoute ist nicht für DoS-Attacken angreifbar
    Das stimmt so aus drei Gründen schon nicht. Zum nutzen Clients immer noch das Internet und wenn ihr Internet-Zugang aufgrund einer DoS-Attacke unsäglich langsam ist, dann hat das durchaus auch Auswirkungen auf die Verbindungen über ExpressRoute.
    Zudem können auch interne Clients unabsichtlich oder absichtlich viel Last auf die ExpressRoute-Leitung bringen, z.B. einen neuen OST-Download oder größere OneDrive-Abgleichen. Auch mit ExpressRoute müssen Sie sich also aktiv Gedanken über ein Traffic-Management machen.
  • ExpressRoute macht Firewalls nicht überflüssig
    Sie haben vielleicht eine "private" Verbindung zu ihren virtuellen Computern und Diensten in ihrem "Azure Private"-Bereich. Zugriff auf Azure Public (ihre Services aber auch die von anderen Tenants) laufen aber ebenfalls über ExpressRoute und die die Zugriffe auf Office 365 erst recht. Bei den  beiden letzten Zielen müssen sie sogar ihre interne private "Source-IP" in eine öffentlichen IP-Adresse umsetzen, z.B. per NAT oder Proxy. Vielleicht möchten Sie auch interne Dienste für Services in Azure erreichbar machen oder beim Exchange Hybrid-Mode das Mail-Routing und die Frei/Belegt-Abfragen entsprechend erreichbar machen. Das bedeutet eine Veröffentlichung von internen Diensten in Richtung Office 365. Auch mit ExpressRoute sind daher auch in die Rückrichtung entsprechende Filter erforderlich.
  • Kein beschränkter Zugriff auf den eigenen Tenant
    Über ExpressRoute haben Sie keinen exklusiven Zugang zu ihrem Tenant. Microsoft betreibt ein "Shared Hosting Model", bei dem unterschiedlichste Firmen und Anwender die gleichen Systeme nutzen aber von einander abgeschottet sind. Die Abschottung ist aber auf Applikationsebene und nicht auf der Transportschicht (IP-Ebene). Über ExpressRoute wird ein interner Anwender auch auf andere Tenants zugreifen. Eine Beschränkung der internen Mitarbeiter auf den eigenen Tenant ist allein mit ExpressRoute nicht möglich.
  • ExpressRoute ändert nichts am vorhandenen LAN/WAN
    Diese Aussage ist definitiv falsch. ExpressRoute funktioniert derart, dass über IP-Leitwege die Pakete zu Office 365/Azure nicht mehr über ihren regulären Weg (Default Gateway, HTTP-Proxy) Richtung Internet geroutet werden, sondern "irgendwie" über den eigenen ExpressRoute-Link. dazu werden aber z.B. ganz viele IP-Subnetze am "Default Gateway" vorbei zu den Firewalls, Proxys und Routern Richtung ExpressRoute geleitet. Auch müssen Sie weitern ihre HTTP-Proxiy-Server, so sie denn solche für den Zugang zu Office 365 bislang genutzt haben, entsprechend umkonfigurieren oder auf dem Client bzw. WPAD-Datei diese Ziele nun als Ausnahme einfügen müssen. Es wird sich also auf jeden Fall etwas ändern. ExpressRoute ist also ein "Projekt" und nicht nur etwas Konfiguration
  • Office 365 Throttling ist nicht umgangen
    Sie haben zwar einen eigenen privaten und mit garantierter Bandbreite ausgestatteten Weg zu Office 365 aber sie landen nicht an der Hintertür oder dem Nebeneinfang sondern auf den gleichen Zugangspunkten, wie Pakete aus dem Internet. Wenn Sie gehofft haben, über ExpressRoute auch eine bevorzugte Behandlung bei Office 365 zu erfahren, dann haben Sie sich getäuscht. Das betrifft gerade auch den Zugriffe auf Postfächer z.B. für Migrationen. Alle Throttling-Mechanismen, die Office 365 und Azure gegen übereifrige Clients einsetzt, bleiben wie bisher erhalten
  • ExpressRoute erspart mir das Internet
    Vielleicht möchten Sie Office 365 für alle Anwender freigeben aber Sie möchten weiterhin restriktiv hinsichtlich des Internet sein. Nehmen wir mal an, ein Anwender oder Standort hätte aus verschiedenen Gründen eben kein Internet. Das ist im Bereich der Energie (z.B. Kraftwerke) und Verteidigung (rotes Netz) durchaus nicht ungewöhnlich für gewisse Systeme. Leider reicht ExpressRote aber nicht, um in solchen Umgebungen Office 365 oder Azure zu nutzen. Bei der Sicherheit muss man sagen, dass speziell Azure-VMs per Default per NAT und Default-Route in das Internet kommen und sie schon daher eine ExpressRoute zu Azure Private in solchen Netzwerken schon gar nicht einrichten können.
    Abe auch für Office 365 ist ein Internet-Zugang erforderlich. ExpressRoute liefert z.B. keine Namensauflösung per DNS. Auch die Software Downloads (Office 365 ProPlus), die Prüfung von Zertifikaten /CRLs), Office Video und andere Dienste benötigen Internet.
    Microsoft empfiehlt die Nutzung des Internets trotz vorhandener ExpressRoute z.B. für ADFS-Proxy, Exchange Hybrid und SharePoint Hybrid
  • ExpressRoute erlaubt schneller eine Anpassung an zunehmenden Datendaten
    Sie können bei Microsoft im Azure Portal sehr einfach ihre ExpressRoute Bandbreite erhöhen aber leider nicht mehr reduzieren. Als temporär mal viel Bandbreite für eine Migration einzurichten geht leider nicht. Aber das ist nur der Übergabepunkt bei Microsoft. Ihren lokale Anbindung und der Transportdurch den ExpressRoute-Provider müssen Sie auch entsprechend anpassen. Nach meiner Erfahrung ist es viel einfacher und schneller möglich die Bandbreite zum Internet zu erweitern als eine ExpressRoute Verbindung einzurichten oder anzupassen. Das hängt aber wohl auch von den individuellen Umständen ab.

Ich will sie nun gar nicht davon abhalten, ExpressRoute in ihre Überlegungen mit einzubeziehen aber Sie sollten genau abwägen, welche Anforderungen Sie wie erfüllen können und welche Erwartungen Sie an die Anbindung stellen. Je mehr sie wissen, desto erfolgreicher werden die Gespräche mit den ein oder anderen ExpressRoute-Providern sein. Das Ergebnis könnte aber auch lauten, dass ExpressRoute gar nicht erforderlich ist oder eine ihrer Internet-Verbindung vergleichbare Anbindung per ExpressRoute den Kostenrahmen übersteigt.

Was kann ich sonst machen ?

Lösen Sie sich erst einmal von dem SLA-Gedanken. Natürlich ist das Stück Übertragungsweg von ihrem Netzwerkausgang bis ins MGN - Microsoft Global Network ein Stück "Wildnis" aber haben Sie schon mal geschaut, ob das wirklich so ist?. Auf der Seite Express Way statt Express Route habe ich schon beschrieben, dass die meisten Firmen von ihrem LAN zu Office 365 in der Regel nur genau einen Provider nutzen. Microsoft baut die Peerings zu den verschiedenen Providern immer weiter aus, da Microsoft ihre Daten ja am besten schnell und zuverlässig bei sich haben will und Provider die Daten damit nicht lange über ihre WAN und teure Peerings weitergeben müssen. Das bedeutet aber dass zwischen Microsoft und ihnen nur ein Vertragspartner steht. Welche "Garantie" gibt ihnen denn ihr heutiger Internet-Provider? Denn es ist nur er, der einen Ausfall auf der Übertragungsstrecke verursachen kann.

Denken Sie aber auch noch mal an die "Wahrscheinlichkeiten". Mit ExpressRoute hätten Sie eine direkte Verbindung zu Microsoft über zwei redundante separate Wege. Das bedeutet natürlich, dass Sie bei sich auch zwei Endpunkte aufgebaut haben. Wenn Sie beide Leitungen auf dem gleichen System terminieren, haben Sie selbst wieder einen Single Point of Failure aufgebaut. Haben Sie denn die beiden Leitungen auch in zwei Rechenzentren verteilt und entspricht ihr gesamtes Netzwerk den Anforderungen die Verfügbarkeit, die Sie die ganze Zeit hochhalten? Sonst hätten Sie sich ja nicht mit ExpressRoute beschäftigt, denn es sind letztlich nur die SLAs, die für ExpressRoute sprechen.

Weitere Links