Routing mit ExpressRoute für Office 365

Um den Routingdatenverkehr mit Office 365 über Azure ExpressRoute richtig zu verstehen, müssen Ihnen die wichtigsten Anforderungen des ExpressRoute-Routings sowie die ExpressRoute-Schaltkreise und Routingdomänen klar sein. Damit werden die Grundlagen für die Nutzung von ExpressRoute festgelegt, auf die Office 365-Kunden angewiesen sind.

Zu einigen der wichtigsten Punkte in den vorstehenden Artikeln, die Sie verstehen müssen, gehören die folgenden:

  • ExpressRoute-Schaltkreise werden nicht einer bestimmten physischen Infrastruktur zugeordnet, sondern sind eine logische Verbindung, die von Microsoft an einem einzelnen Peeringstandort und von einem Peeringanbieter in Ihrem Auftrag hergestellt werden.

  • Es gibt eine 1:1-Zuordnung zwischen einem ExpressRoute-Schaltkreis und dem s-Schlüssel eines Kunden.

  • Jeder Schaltkreis kann bis zu 3 unabhängige Peeringbeziehungen (öffentliches Azure-Peering, privates Azure-Peering und Microsoft-Peering) unterstützen; für Office 365 ist Microsoft-Peering erforderlich.

  • Jeder Schaltkreis verfügt über eine feste Bandbreite, die von allen Peeringbeziehungen gemeinsam genutzt wird.

  • Bei öffentlichen IPv4-Adressen und öffentlichen AS-Nummern, die für den ExpressRoute-Schaltkreis verwendet werden, muss überprüft worden sein, dass Sie der Besitzer sind, oder sie müssen Ihnen vom Besitzer des Adressbereichs exklusiv zugewiesen worden sein.

  • ExpressRoute-Schaltkreise selbst sind global redundant und folgen den Standardmethoden für BGP-Routing.

Weitere Informationen zu unterstützten Diensten, Kosten und Konfigurationsdetails finden Sie auf der FAQ-Seite mit den häufig gestellten Fragen. Informationen zur Liste von Konnektivitätsanbietern, die Support für Microsoft-Peering bieten, finden Sie im Artikel ExpressRoute-Standorte.

Hinweis : Azure ExpressRoute für Office 365 kann noch nicht mit IPv6 verwendet werden. Sie müssen IPv6 deaktivieren, da sonst standardmäßig IPv6 und nicht die ExpressRoute-Verbindung als Verbindung verwendet wird.

Die Infrastruktur, die den Kundendatenverkehr für Office 365-Anwendungen akzeptiert, ist sowohl über das Internet als auch über ExpressRoute bzw. mehrere ExpressRoute-Verbindungen zugänglich. Der Netzwerkdatenverkehr von Office 365 zum Kundennetzwerk durchläuft ExpressRoute, wenn sowohl das Internet als auch ExpressRoute zur Verfügung stehen. Dadurch wird eine Routenasymmetrie möglich, wenn der Datenverkehr aus dem Kundennetzwerk bevorzugt die Internetroute durchläuft. Asymmetrische Routen sind ein Problem, weil Geräte, die eine zustandsbehaftete Paketprüfung durchführen, den Rückgabedatenverkehr blockieren können, der einem anderen Pfad als die ausgehenden Pakete folgt.

Wenn ein Kundencomputer eine Verbindung zu Office 365 über das Internet initiiert, müssen die der Anforderung zugeordneten Kundenendpunkte öffentlich routingfähig sein. Das gleiche gilt für vom Kunden initiierte Verbindungen über ExpressRoute. Bei vielen Kunden, die ein Peering direkt mit Microsoft durchführen, ist es nicht praktikabel, über private Adressen zu verfügen, bei denen eine Duplizierung zwischen Kunden möglich ist.

Nachstehend sind Szenarien aufgeführt, in denen eine Kommunikation von Office 365 zu Ihrem lokalen Netzwerk initiiert wird:

Damit Microsoft diesen bidirektionalen Datenverkehr zurück zu Ihrem Netzwerk leiten kann, müssen die BGP-Routen zu den lokalen Geräten für Microsoft freigegeben werden.

Zum Herstellen einer Verbindung mit Office 365 über einen ExpressRoute-Schaltkreis müssen Sie eine Peeringbeziehung über die Routingdomäne von Microsoft-Peering konfigurieren. Öffentliches und privates Azure-Peering sind bei Office 365 nicht erforderlich. Es gibt allerdings mit Office 365 verbundene Dienste, die die öffentliche Azure-Routingdomäne benötigen. Beispielsweise bauen Azure RemoteApp und das Office 365-Verwaltungspaket auf Microsoft Azure auf. Da es sich hier um eine in Azure erstellte Anwendung handelt, stehen einige der Endpunkte über öffentliches Azure-Peering zur Verfügung.

Bei anderen Anwendungen, z. B. Office 365 Video, handelt es sich um Office 365-Anwendungen. Office 365 Video besteht jedoch aus drei verschiedenen Komponenten – dem Portal, dem Streamingdienst und dem Netzwerk für die Inhaltsübermittlung (Content Delivery Network, CDN). Das Portal befindet sich in SharePoint Online, der Streamingdienst in Azure Media Services und das Content Delivery Network im Azure CDN. In der nachstehenden Tabelle werden diese Komponenten kurz erläutert.

Komponente

Zugrunde liegende Anwendung

Routingdomäne

Verwendung

Office 365 Video-Portal

SharePoint Online

Microsoft-Peering

Konfiguration, Upload

Office 365 Video-Streamingdienst

Azure Media Services

Öffentliches Azure-Peering

Streamingdienst – verwendet, wenn das Video aus dem CDN nicht verfügbar ist

Content Delivery Network für Office 365 Video

Azure CDN

Keine

Primäre Datenquelle für Download/Streaming von Videos. Weitere Informationen zu Office 365-Videonetzwerken.

Während Azure RemoteApp, das Office 365-Verwaltungspaket und Office 365 Video die einzigen Anwendungen sind, die feste Abhängigkeiten von der öffentlichen Azure-Routingdomäne aufweisen, ist dies möglicherweise für weitere Anwendungen in der Zukunft erforderlich. Wenn Sie verstehen möchten, welche Office 365-Features und -Anwendungen verfügbar sind, lesen Sie den Artikel zu Office 365-Endpunkte. Für jede Anwendung gibt es eine Spalte, in der angegeben ist, ob das Feature mit Microsoft-Peering verfügbar ist oder nicht.

Die einzelnen über Microsoft-Peering verfügbaren Office 365-Features werden im Artikel Office 365-Endpunkte nach Anwendungstyp und vollqualifizierten Domänennamen (FQDN) aufgelistet. Der Grund für die Verwendung des vollqualifizierten Domänennamens in den Tabellen besteht darin, den Kunden das Verwalten des Datenverkehrs mithilfe von PAC-Dateien oder anderen Proxykonfigurationen zu ermöglichen. Die für jede Anwendung erforderlichen IP-Adressen sind auf Anwendungsebene und nicht auf Featureebene aufgeteilt. Bei jeder Anwendung, die über ExpressRoute zur Verfügung steht, sind die IP-Adressbereiche in einer separaten Tabelle aufgeführt. Bei den IP-Bereichen, die nur über das Internet und sowohl über das Internet als auch ExpressRoute zur Verfügung stehen, sind Details hinzugefügt.

Diese IP-Adressen sind in BGP-Communitykategorien gruppiert, um die Routingverwaltung zu vereinfachen. Zu den verwendeten Communitykategorien zählen:

Community-Zeichenfolgenkategorie

Enthaltene Anwendungen

Exchange

Exchange Online

Exchange Online Protection

Skype for Business

Skype for Business Online

SharePoint

SharePoint Online

Andere Office 365-Dienste

Portal und gemeinsame Dienste

Authentifizierung und Identität

Office Online

Die meisten der als "für ExpressRoute und das Internet angekündigt" aufgeführten FQDNs sind allumfassend. In einigen Fällen haben wir einen Platzhalter in einem FQDN in einer Situation verwendet, in der ein oder mehrere untergeordnete FQDNs anders als der Platzhalter-FQDN auf höherer Ebene angekündigt wurden. Dies geschieht in der Regel, wenn der Platzhalter eine lange Liste von Servern darstellt, die alle für ExpressRoute und das Internet angekündigt werden, und es eine kleine Untergruppe von Servern oder CNAMEs gibt, die nur für das Internet angekündigt werden oder umgekehrt. Informationen zu den jeweiligen Unterschieden finden Sie in den nachfolgenden Tabellen.

In dieser Tabelle werden die Platzhalter-FQDNs, die sowohl für das Internet als auch für Azure ExpressRoute angekündigt werden, zusammen mit den untergeordneten FQDNs angezeigt, die nur für das Internet angekündigt werden.

Für ExpressRoute und das Internet angekündigter Platzhalter-FQDN

Nur für das Internet angekündigter untergeordneter FQDN

*.microsoftonline.com

click.email.microsoftonline.com

portal.microsoftonline.com

*.officeapps.live.com

NexusRules.officeapps.live.com

Nexus.officeapps.live.com

odc.officeapps.live.com

odc.officeapps.live.com

cdn.odc.officeapps.live.com

ols.officeapps.live.com

ocsredir.officeapps.live.com

ocws.officeapps.live.com

ocsa.officeapps.live.com

In der Regel sollen PAC-Dateien die Netzwerkanforderungen an für ExpressRoute angekündigte Endpunkte direkt in den Pfad und alle anderen Netzwerkanforderungen an Ihren Proxy senden. Wenn Sie eine PAC-Datei entsprechend konfigurieren, stellen Sie Ihre PAC-Datei in der folgenden Reihenfolge zusammen:

  1. Schließen Sie die untergeordneten FQDNs aus der zweiten Spalte der obigen Tabelle am Anfang der PAC-Datei ein, wodurch der Datenverkehr an den Proxy gesendet wird.

  2. Beziehen Sie alle FQDNs, die in diesem Artikel als "für ExpressRoute angekündigt" markiert sind, unter dem ersten Abschnitt ein, wodurch der Datenverkehr direkt an den ExpressRoute-Pfad gesendet wird.

  3. Beziehen Sie alle anderen Netzwerkendpunkte oder Regeln unter diesen beiden Einträgen ein, wodurch der Datenverkehr an Ihren Proxy gesendet wird.

In dieser Tabelle werden die Platzhalter-FQDNs, die nur für das Internet angekündigt werden, zusammen mit den untergeordneten FQDNs angezeigt, die für Azure ExpressRoute und das Internet angekündigt werden. Für Ihre obige PAC-Datei werden die FQDNs in der zweiten Spalte der nachfolgenden Tabelle im aufgeführten Link als "für ExpressRoute angekündigt" aufgelistet, d. h. sie würden in die zweite Gruppe von Einträgen in der Datei einbezogen werden.

Nur für das Internet angekündigter Platzhalter-FQDN

Für ExpressRoute und das Internet angekündigter untergeordneter FQDN

*.office.com

*.outlook.office.com

home.office.com

portal.office.com

www.office.com

*.office.net

agent.office.net

*.office365.com

outlook.office365.com

smtp.office365.com

*.outlook.com

*.protection.outlook.com

*.mail.protection.outlook.com

*.windows.net

login.windows.net

Für das Routing zur gewählten Office 365-Anwendung müssen Sie eine Reihe von wichtigen Faktoren ermitteln:

  1. Die für die Anwendung erforderliche Bandbreite – Stichproben hinsichtlich der vorhandenen Nutzung sind die einzige zuverlässige Methode zur Ermittlung dieser Werte in Ihrem Unternehmen. Verwenden Sie unsere Rechner lediglich als Ausgangspunkt.

  2. Über welche Ausgangspunkte der Netzwerkdatenverkehr Ihr Netzwerk verlassen soll – Sie sollten die Minimierung der Netzwerklatenz für die Verbindungen zu Office 365 planen, da sich dies auf die Leistung auswirkt. Weil Skype for Business Sprach- und Videofunktionen in Echtzeit verwendet, ist es besonders anfällig für schlechte Netzwerklatenzen.

  3. Wenn Sie planen, dass alle oder ein Teil Ihrer Netzwerkspeicherorte ExpressRoute nutzen sollen.

  4. Über welche Speicherorte Ihr gewählter Netzwerkdienstanbieter ExpressRoute anbietet.

Nachdem Sie die Antworten auf diese Fragen ermittelt haben, können Sie einen ExpressRoute-Schaltkreis bereitstellen, der die Anforderungen an die Bandbreite und den Speicherort erfüllt. Weitere Unterstützung zur Netzwerkplanung finden Sie im Office 365-Handbuch zur Netzwerkoptimierung und in der Fallstudie zur Vorgehensweise von Microsoft beim Planen der Netzwerkleistung.

Beispiel 1: Einzelner geografischer Standort

Dieses Beispiel ist ein Szenario für die fiktive Firma Trey Research, die über einen einzigen geografischen Standort verfügt.

Mitarbeitern von Trey Research ist es nur gestattet, eine Verbindung mit den Diensten und Websites im Internet herzustellen, die von der Sicherheitsabteilung auf den zwei ausgehenden Proxys, die sich zwischen dem Unternehmensnetzwerk und dem Internetdienstanbieter befinden, explizit zugelassen sind.

Trey Research beabsichtigt, Azure ExpressRoute für Office 365 zu verwenden, und erkennt, dass ein Teil des Datenverkehrs, z. B. Datenverkehr an Content Delivery Networks, nicht über die ExpressRoute für Office 365-Verbindung geleitet werden kann. Da der gesamte Datenverkehr bereits standardmäßig an die Proxygeräte geleitet wird, werden diese Anforderungen weiterhin wie gewohnt ausgeführt. Nachdem Trey Research festgestellt hat, dass die Azure ExpressRoute-Routinganforderungen erfüllt werden können, wird damit begonnen, einen Schaltkreis zu erstellen, das Routing zu konfigurieren und den neuen ExpressRoute-Schaltkreis mit einem virtuellen Netzwerk zu verknüpfen. Sobald die grundlegende Azure ExpressRoute-Konfiguration vorhanden ist, fügt Trey Research die von ExpressRoute für Office 365 unterstützten Office 365-Endpunkte zu einer Datei für automatische Proxykonfiguration (Automatic Proxy Configuration, PAC) oder die URL hinzu, um den Verkehr kundenspezifischer Daten über die direkten ExpressRoute für Office 365-Verbindungen zu leiten.

Wie im folgenden Diagramm veranschaulicht, kann Trey Research die Anforderungen hinsichtlich der Weiterleitung des Office 365-Datenverkehrs über das Internet und einer Teilmenge des Datenverkehrs über ExpressRoute mithilfe einer Kombination aus Routing und Änderungen an der ausgehenden Proxykonfiguration erfüllen.

  1. Eine Datei für automatische Proxykonfiguration (PAC-Datei) und eine URL werden verwendet, um den Datenverkehr über einen separaten Internet-Ausgangspunkt für Azure ExpressRoute für Office 365 zu leiten.

  2. Clients sind mit einer Standardroute zu den Proxys von Trey Research konfiguriert.

In diesem Beispielszenario verwendet Trey Research ein ausgehendes Proxygerät. Vielleicht möchten auch Kunden, die Azure ExpressRoute für Office 365 nicht verwenden, dieses Verfahren nutzen, um das Routing des Datenverkehrs basierend auf den Kosten vorzunehmen, die für die Überprüfung des für bekannte Endpunkte mit hohem Volumen bestimmten Datenverkehrs anfallen.

Die FQDNs mit dem höchsten Volumen für Exchange Online, SharePoint Online und Skype for Business Online sind die Folgenden:

ExpressRoute - Kundenumkreisnetzwerk
  • outlook.office365.com

  • outlook.office.com

  • <Mandantenname>.sharepoint.com

  • <Mandantenname>-my.sharepoint.com

  • <Mandantenname>-<App>.sharepoint.com

  • *.Lync.com

Erfahren Sie mehr über das Bereitstellen und Verwalten von Proxyeinstellungen in Windows 8 und Sicherstellen, dass Office 365 nicht durch den Proxy gedrosselt wird.

Mit einem einzelnen ExpressRoute-Schaltkreis gibt es keine hohe Verfügbarkeit für Trey Research. Für den Fall, dass das redundante Edgegerätepaar von Trey Research fehlschlägt, das die ExpressRoute-Verbindungen instand hält, gibt es keinen weiteren ExpressRoute-Schaltkreis für einen Failover. Dadurch gerät Trey Research in eine Zwangslage, da ein Failover über das Internet eine manuelle Neukonfiguration und in einigen Fällen neue IP-Adressen erfordert. Wenn Trey eine hohe Verfügbarkeit haben möchte, ist es am einfachsten, weitere ExpressRoute-Schaltkreise hinzuzufügen.

Das letzte Szenario mit dem Routing von Office 365-Datenverkehr über ExpressRoute bildet die Grundlage für eine noch komplexere Routingarchitektur. Unabhängig von der Anzahl der Standorte, der Anzahl der Kontinente, auf denen sich diese Speicherorte befinden, der Anzahl der ExpressRoute-Schaltkreise usw. ist das Routing von Datenverkehr über das Internet und über ExpressRoute erforderlich.

Weitere Fragen, die für Kunden mit mehreren Standorten in verschiedenen Regionen beantwortet werden müssen:

  1. Benötigen sie einen ExpressRoute-Schaltkreis an jedem Standort? Wenn Skype for Business verwendet wird oder der Kunde hinsichtlich der Latenzempfindlichkeit für SharePoint Online oder Exchange Online Bedenken hat, wird ein ExpressRoute-Schaltkreis auf jedem Kontinent empfohlen, auf dem der Kunde über Zweigniederlassungen verfügt. Weitere Informationen finden Sie im Handbuch zu Medienqualität und Netzwerkverbindung für Skype for Business.

  2. Wie soll der an Office 365 gerichtete Datenverkehr geleitet werden, wenn in einer bestimmten Region kein ExpressRoute-Schaltkreis verfügbar ist?

  3. Welche Methode wird für die Konsolidierung von Datenverkehr bevorzugt bei Netzwerken mit vielen kleinen Standorten verwendet?

Jedes dieser Netzwerke stellt eine unverwechselbare Herausforderung dar, die von Ihnen die Auswertung Ihres eigenen Netzwerks sowie der von Microsoft verfügbaren Optionen erfordert.

Überlegungen

Auszuwertende Netzwerkkomponenten

Schaltkreise an mehreren Standorten

Anforderungen an Kosten, Latenz und Bandbreite müssen verglichen werden.

Verwendung von BGP-Routenkosten, PAC-Dateien und NAT zum Verwalten des Routings mit mehreren Schaltkreisen.

Routing von Standorten ohne ExpressRoute-Schaltkreis

Mithilfe von DNS-Weiterleitung kann es Zweigniederlassungen ermöglicht werden, den geeigneten Endpunkt zu ermitteln.

Für Clients in einer Zweigniederlassung muss eine Route verfügbar sein, die Zugriff auf den ExpressRoute-Schaltkreis bietet.

Konsolidierung bei Zweigniederlassungen

Verfügbare Bandbreite und Datennutzung sollten sorgfältig verglichen werden.

Hinweis : Microsoft bevorzugt ExpressRoute über das Internet, wenn die Route unabhängig vom physischen Standort verfügbar ist.

Jede dieser Überlegungen muss bei jedem einzelnen Netzwerk berücksichtigt werden. Schauen Sie sich das nachstehende Beispiel an.

Beispiel 2: Mehrere geografische Standorte

Dieses Beispiel ist ein Szenario für die fiktive Firma Humongous Insurance, die über mehrere geografische Standorte verfügt.

Humongous Insurance ist mit Zweigniederlassungen auf der ganzen Welt geografisch weit verteilt, die Azure ExpressRoute für Office 365 implementieren werden, damit der Großteil des Office 365-Datenverkehrs in direkten Netzwerkverbindungen erfolgt. Humongous Insurance verfügt außerdem über Zweigniederlassungen auf zwei weiteren Kontinenten. Die Mitarbeiter der Zweigniederlassung, bei der ExpressRoute nicht praktikabel ist, müssen den Datenverkehr an eine der beiden Zentralen zurückleiten, um eine ExpressRoute-Verbindung verwenden zu können.

Der Leitsatz lautet: Dafür sorgen, dass für Office 365 bestimmter Datenverkehr schnellstmöglich zu einem Microsoft-Datencenter gelangt. In diesem Beispiel muss Humongous Insurance entscheiden, ob seine Zweigstellen den Datenverkehr über das Internet leiten, um so schnell wie möglich über eine beliebige Verbindung zu einem Microsoft-Datencenter zu gelangen, oder ob die Zweigstellen das Routing über ein internes Netzwerk nutzen, um ein Microsoft-Datencenter schnellstmöglich über eine ExpressRoute-Verbindung zu erreichen.

Datencenter, Netzwerke und Anwendungsarchitektur von Microsoft sollen global verteilte Kommunikation übernehmen und möglichst effizient bereitstellen. Für Office 365 bestimmte Anforderungen, die länger als nötig in Kundennetzwerken bleiben, können diese Architektur nicht nutzen.

In dieser Situation sollten die Mitarbeiter von Humongous Insurance entsprechend den Anwendungen verfahren, die sie über ExpressRoute nutzen möchten. Wenn Humongous Insurance z. B. Skype for Business Online-Kunde ist oder plant, ExpressRoute-Verbindungen zum Herstellen einer Verbindung zu externen Skype for Business Online-Besprechungen zu nutzen, wird im Handbuch zu Medienqualität und Netzwerkverbindungen für Skype for Business Online empfohlen, für diesen dritten Standort einen weiteren ExpressRoute-Schaltkreis bereitzustellen. Dies ist möglicherweise im Hinblick auf die Netzwerke kostenaufwendiger, aber Routinganforderungen zwischen Kontinenten, die vor der Bereitstellung in einem Microsoft-Datencenter erfolgen, führen während Skype for Business Online-Besprechungen und der entsprechenden Kommunikation möglicherweise zu schlechten oder unbrauchbaren Erfahrungen.

Wenn Humongous Insurance Skype for Business Online weder nutzt noch die Nutzung in irgendeiner Weise plant, ist das Routing des für Office 365 bestimmten Netzwerkdatenverkehrs über einen Kontinent mit einer ExpressRoute-Verbindung möglicherweise praktikabel. In beiden Fällen wird das Routing von Datenverkehr, der auf das Internet ausgerichtet ist, an das am lokalen Standort verfügbare Internet empfohlen, um die Content Delivery Networks zu nutzen, auf denen Office 365 beruht.

ExpressRoute - mehrere geografische Standorte

Wenn Humongous Insurance seine Strategie mit mehreren geografischen Standorten plant, müssen eine Reihe von Faktoren hinsichtlich der Schaltkreisgröße (hier besprochen), der Anzahl der Schaltkreise, des Failovers usw. berücksichtigt werden.

Mit einer ExpressRoute-Verbindung an einem einzelnen Standort mit mehreren Regionen, die versuchen, den Schaltkreis zu nutzen, möchte Humongous Insurance sicherstellen, dass Verbindungen zu/von Office 365 von der Zweigniederlassung an das Office 365-Datencenter gesendet werden, das der Zentrale am nächsten liegt, und am Standort der Zentrale empfangen werden. Zu diesem Zweck implementiert Humongous Insurance eine DNS-Weiterleitung, um die Anzahl von Roundtrips und DNS-Suchvorgängen zu verringern, die zum Herstellen der entsprechenden Verbindung mit der Office 365-Umgebung erforderlich sind, die dem Internet-Ausgangspunkt der Zentrale am nächsten ist. Es stehen außerdem Informationen zum Zuweisen einer bedingten Weiterleitung für einen Domänennamen bereit.

In diesem Szenario würde der Datenverkehr von der Zweigniederlassung die Office 365-Front-End-Infrastruktur in Nordamerika auflösen und Office 365 nutzen, um gemäß der Architektur der Office 365-Anwendung eine Verbindung zu den Back-End-Servern herzustellen. Exchange Online würde z. B. die Verbindung in Nordamerika beenden, und diese Front-End-Server würden je nach Standort des Mandanten eine Verbindung mit dem Back-End-Postfachserver herstellen. Weitere Informationen zum Entwurf der einzelnen Anwendungen zur Behandlung der Clientkonnektivität finden Sie unter "Clientkonnektivität".

Wenn Humongous Insurance über große Zweigstellen auf verschiedenen Kontinenten verfügt, wird mindestens ein Schaltkreis pro Kontinent empfohlen, um die Latenz für vertrauliche Anwendungen wie Skype for Business zu verringern. Wenn sich alle Zweigniederlassungen auf einem einzigen Kontinent befinden oder wenn keine Zusammenarbeit in Echtzeit erfolgen soll, stellt die Verwendung eines konsolidierten oder verteilten Ausgangspunkts eine kundenspezifische Entscheidung dar, die von der Anzahl der Personen pro Standort, der Nutzung der Anwendung an den einzelnen Standorten, den Anforderungen an die hohe Verfügbarkeit usw. abhängen würde. Wenn mehrere Schaltkreise zur Verfügung stehen, stellt BGP-Routing das Failover für den Fall sicher, dass ein einzelner Schaltkreis nicht mehr verfügbar ist.

Weitere Informationen zu Beispielen für Routerkonfigurationen und https://azure.microsoft.com/de-de/documentation/articles/expressroute-config-samples-nat/.

Selektives Routing mit ExpressRoute kann aus einer Vielzahl von Gründen erforderlich sein, z. B. zum Testen oder zur Einführung von ExpressRoute bei einer Teilmenge von Benutzern. Es gibt verschiedene Tools, mit denen Benutzer Office 365-Netzwerkdatenverkehr selektiv über ExpressRoute leiten können:

  1. Routenfilterung/Trennung – ermöglichen BGP-Routen zu Office 365 über ExpressRoute zu einer Teilmenge von Subnetzen oder Routern. Damit werden Routen selektiv nach Kundennetzwerksegment oder physischem Bürostandort geroutet. Dies ist für gestaffelte Rollouts von ExpressRoute für Office 365 üblich.

  2. PAC-Dateien/URLs – weisen für Office 365 bestimmten Netzwerkdatenverkehr für bestimmte FQDNs zum Leiten auf einem spezifischen Pfad. Damit erfolgt das Routing, entsprechend der Identifizierung durch PAC-Dateibereitstellung, selektiv nach Clientcomputer.

  3. BGP-Communitys – durch Filtern aufgrund der BGP-Communitykategorien kann ein Kunde bestimmen, welche Office 365-Anwendungen ExpressRoute durchlaufen werden und welche das Internet.

    Hinweis : BGP-Communitys für ExpressRoute werden in Kürze veröffentlicht.

Siehe auch

Netzwerkkonnektivität mit Office 365

Azure ExpressRoute für Office 365

Netzwerkplanung mit ExpressRoute für Office 365

Implementieren von ExpressRoute für Office 365

Medienqualität und Netzwerkverbindungsleistung in Skype for Business Online

Optimieren Ihres Netzwerks für Skype for Business Online

ExpressRoute und QoS in Skype for Business Online

Anruffluss mit ExpressRoute

Verwenden von BGP-Communitys in ExpressRoute für Office 365-Szenarien (Vorschau)

Office 365-Leistungsoptimierung mithilfe von Basiswerten und dem Leistungsverlauf

Behandlung von Leistungsproblemen – Plan für Office 365

URLs und IP-Adressbereiche von Office 365

Netzwerkplanung und Leistungsoptimierung für Office 365

Teilen Facebook Facebook Twitter Twitter E-Mail E-Mail

War diese Information hilfreich?

Sehr gut. Noch anderes Feedback?

Was können wir verbessern?

Vielen Dank für Ihr Feedback!

×