Implementierung von ExpressRoute für Microsoft 365
Dieser Artikel gilt für Microsoft 365 Enterprise.
ExpressRoute für Microsoft 365 bietet einen alternativen Routingpfad zu vielen Microsoft 365-Diensten mit Internetzugriff. Die Architektur von ExpressRoute für Microsoft 365 basiert auf der Ankündigung öffentlicher IP-Präfixe von Microsoft 365-Diensten, auf die bereits über das Internet in Ihren bereitgestellten ExpressRoute-Leitungen zugegriffen werden kann, um diese IP-Präfixe anschließend in Ihr Netzwerk weiterzuverteilen. Mit ExpressRoute ermöglichen Sie effektiv mehrere verschiedene Routingpfade, über das Internet und über ExpressRoute, für viele Microsoft 365-Dienste. Dieser Zustand des Routings in Ihrem Netzwerk kann eine erhebliche Änderung der Art und Art und Art der Internen Netzwerktopologie darstellen.
Hinweis
ExpressRoute für Microsoft 365 wird nicht empfohlen , da es in den meisten Fällen nicht das beste Konnektivitätsmodell für den Dienst bietet. Daher ist für die Verwendung dieses Konnektivitätsmodells eine Microsoft-Autorisierung erforderlich. Wir überprüfen jede Kundenanfrage und autorisieren ExpressRoute für Microsoft 365 nur in den seltenen Szenarien, in denen dies erforderlich ist. Lesen Sie den ExpressRoute für Microsoft 365-Leitfaden, um weitere Informationen zu erhalten, und arbeiten Sie nach einer umfassenden Überprüfung des Dokuments mit Ihren Produktivitäts-, Netzwerk- und Sicherheitsteams mit Ihrem Microsoft-Kontoteam zusammen, um bei Bedarf eine Ausnahme zu übermitteln. Nicht autorisierte Abonnements, die versuchen, Routenfilter für Microsoft 365 zu erstellen, erhalten eine Fehlermeldung.
Sie müssen Ihre ExpressRoute für Microsoft 365-Implementierung sorgfältig planen, um die Netzwerkkomplexität des Routings über eine dedizierte Leitung mit Routen, die in Ihr Kernnetzwerk und das Internet eingefügt werden, zu berücksichtigen. Wenn Sie und Ihr Team die detaillierte Planung und Tests in diesem Leitfaden nicht durchführen, besteht ein hohes Risiko, dass es zu zeitweiligen oder totalen Konnektivitätsverlusten mit Microsoft 365-Diensten kommt, wenn die ExpressRoute-Verbindung aktiviert ist.
Für eine erfolgreiche Implementierung müssen Sie Ihre Infrastrukturanforderungen analysieren, detaillierte Netzwerkbewertungen und -entwürfe durchlaufen, den Rollout gestaffelt und kontrolliert sorgfältig planen und einen detaillierten Validierungs- und Testplan erstellen. Bei einer großen, verteilten Umgebung ist es nicht ungewöhnlich, dass Implementierungen mehrere Monate umfassen. Dieser Leitfaden soll Ihnen helfen, vorauszuplanen.
Große erfolgreiche Bereitstellungen können sechs Monate in der Planung dauern und umfassen häufig Teammitglieder aus vielen Bereichen der organization einschließlich Netzwerk, Firewall- und Proxyserveradministratoren, Microsoft 365-Administratoren, Sicherheit, Endbenutzersupport, Projektmanagement und Unterstützung durch Führungskräfte. Ihre Investition in den Planungsprozess verringert die Wahrscheinlichkeit, dass Bereitstellungsfehler auftreten, die zu Ausfallzeiten oder einer komplexen und kostspieligen Problembehandlung führen.
Wir erwarten, dass die folgenden Voraussetzungen erfüllt sind, bevor dieser Implementierungsleitfaden gestartet wird.
Sie haben eine Netzwerkbewertung abgeschlossen, um festzustellen, ob ExpressRoute empfohlen und genehmigt wird.
Sie haben einen ExpressRoute-Netzwerkdienstanbieter ausgewählt. Hier finden Sie Details zu den ExpressRoute-Partnern und Peeringstandorten.
Sie haben die ExpressRoute-Dokumentation bereits gelesen und verstanden, und Ihr internes Netzwerk kann die ExpressRoute-Voraussetzungen vollständig erfüllen.
Ihr Team hat alle öffentlichen Anleitungen und Dokumentationen unter https://aka.ms/expressrouteoffice365gelesen https://aka.ms/ertund sich die Azure ExpressRoute für Microsoft 365-Schulungsreihe auf Channel 9 angesehen, um ein Verständnis wichtiger technischer Details zu erhalten, einschließlich:
Die Internetabhängigkeiten von SaaS-Diensten.
Erfahren Sie, wie Sie asymmetrische Routen vermeiden und komplexes Routing behandeln.
Hier erfahren Sie, wie Sie Sicherheits-, Verfügbarkeits- und Anwendungssteuerungen auf Umkreisebene integrieren.
Beginnen Sie mit dem Sammeln von Anforderungen
Legen Sie zunächst fest, welche Features und Dienste Sie in Ihrem organization einführen möchten. Sie müssen bestimmen, welche Features der verschiedenen Microsoft 365-Dienste verwendet werden und an welchen Standorten in Ihrem Netzwerk Personen gehostet werden, die diese Features verwenden. Mit dem Katalog von Szenarien müssen Sie die Netzwerkattribute hinzufügen, die für jedes dieser Szenarien erforderlich sind. z. B. eingehender und ausgehender Netzwerkdatenverkehr und ob die Microsoft 365-Endpunkte über ExpressRoute verfügbar sind oder nicht.
So erfassen Sie die Anforderungen Ihrer organization:
Katalogisieren Sie den eingehenden und ausgehenden Netzwerkdatenverkehr für die Microsoft 365-Dienste, die Ihr organization verwendet. Eine Beschreibung der Flows, die in verschiedenen Microsoft 365-Szenarien erforderlich sind, finden Sie auf der Seite microsoft 365-URLs und IP-Adressbereiche.
Sammeln Sie Eine Dokumentation der vorhandenen Netzwerktopologie mit Details zu Ihrem internen WAN-Backbone und ihrer Topologie, der Konnektivität von Satellitenstandorten, der Benutzerkonnektivität der letzten Meile, des Routings zu ausgehenden Netzwerkperimeterpunkten und Proxydiensten.
Identifizieren Sie eingehende Dienstendpunkte in den Netzwerkdiagrammen, mit denen Microsoft 365 und andere Microsoft-Dienste eine Verbindung herstellen, und zeigen sowohl das Internet als auch die vorgeschlagenen ExpressRoute-Verbindungspfade an.
Identifizieren Sie alle geografischen Benutzerstandorte und DIE WAN-Konnektivität zwischen Standorten sowie die Standorte, an denen derzeit ein Ausgang zum Internet besteht und an welchen Standorten ein Ausgehender Datenverkehr zu einem ExpressRoute-Peeringstandort vorgeschlagen wird.
Identifizieren Sie alle Edgegeräte, z. B. Proxys, Firewalls usw., und katalogisieren Sie deren Beziehung zu Flows, die über das Internet und ExpressRoute gehen.
Dokumentieren Sie, ob Endbenutzer auf Microsoft 365-Dienste über Direct Routing oder einen indirekten Anwendungsproxy für Internet- und ExpressRoute-Flows zugreifen.
Fügen Sie dem Netzwerkdiagramm den Standort Ihres Mandanten und der Meet-me-Standorte hinzu.
Schätzen Sie die erwarteten und beobachteten Netzwerkleistungs- und Latenzmerkmale von wichtigen Benutzerstandorten zu Microsoft 365. Denken Sie daran, dass Microsoft 365 eine globale und verteilte Gruppe von Diensten ist und Benutzer verbindungen mit Standorten herstellen, die sich von dem Standort ihres Mandanten unterscheiden können. Aus diesem Grund wird empfohlen, die Latenz zwischen dem Benutzer und dem nächstgelegenen Rand des globalen Microsoft-Netzwerks über ExpressRoute- und Internetverbindungen zu messen und zu optimieren. Sie können Ihre Ergebnisse aus der Netzwerkbewertung verwenden, um diese Aufgabe zu unterstützen.
Listet die Sicherheits- und Hochverfügbarkeitsanforderungen des Unternehmens auf, die mit der neuen ExpressRoute-Verbindung erfüllt werden müssen. Beispielsweise, wie Benutzer weiterhin Zugriff auf Microsoft 365 erhalten, wenn der Internetausgang oder ein ExpressRoute-Leitungsfehler auftritt.
Dokumentieren Sie, welche ein- und ausgehenden Microsoft 365-Netzwerkflows den Internetpfad und welche ExpressRoute verwenden. Aufgrund der Besonderheiten der geografischen Standorte Ihrer Benutzer und der Details Ihrer lokalen Netzwerktopologie muss sich der Plan möglicherweise von einem Benutzerstandort zu einem anderen unterscheiden.
Katalogisieren Des ausgehenden und eingehenden Netzwerkdatenverkehrs
Um Routing und andere Netzwerkkomplexitäten zu minimieren, empfehlen wir Ihnen, ExpressRoute für Microsoft 365 nur für die Netzwerkdatenverkehrsflüsse zu verwenden, die aufgrund gesetzlicher Anforderungen oder als Ergebnis der Netzwerkbewertung über eine dedizierte Verbindung geleitet werden müssen. Darüber hinaus wird empfohlen, den Umfang des ExpressRoute-Routings zu stufen und ausgehenden und eingehenden Netzwerkdatenverkehr als unterschiedliche und unterschiedliche Phasen des Implementierungsprojekts anzugehen. Die Bereitstellung von ExpressRoute für Microsoft 365 nur für vom Benutzer initiierte ausgehende Netzwerkdatenverkehrsflüsse und verlassen eingehender Netzwerkdatenverkehr über das Internet kann dazu beitragen, die zunahme der topologischen Komplexität und das Risiko der Einführung zusätzlicher asymmetrischer Routingmöglichkeiten zu steuern.
Ihr Netzwerkdatenverkehrskatalog sollte Auflistungen aller ein- und ausgehenden Netzwerkverbindungen zwischen Ihrem lokalen Netzwerk und Microsoft enthalten.
Ausgehende Netzwerkdatenverkehrsflüsse sind alle Szenarien, in denen eine Verbindung aus Ihrer lokalen Umgebung initiiert wird, z. B. von internen Clients oder Servern, mit einem Ziel der Microsoft-Dienste. Diese Verbindungen können direkt mit Microsoft 365 oder indirekt erfolgen, z. B. wenn die Verbindung über Proxyserver, Firewalls oder andere Netzwerkgeräte auf dem Pfad zu Microsoft 365 erfolgt.
Eingehende Netzwerkdatenverkehrsflüsse sind alle Szenarien, in denen eine Verbindung von der Microsoft-Cloud zu einem lokalen Host initiiert wird. Diese Verbindungen müssen in der Regel eine Firewall und eine andere Sicherheitsinfrastruktur durchlaufen, die die Kundensicherheitsrichtlinie für extern entstandene Flows erfordert.
Lesen Sie den Abschnitt Sicherstellen der Routensymmetrie, um zu ermitteln, welche Dienste eingehenden Datenverkehr senden, und suchen Sie im Referenzartikel zu Microsoft 365-Endpunkten nach der Spalte ExpressRoute für Microsoft 365, um die restlichen Konnektivitätsinformationen zu ermitteln.
Für jeden Dienst, der eine ausgehende Verbindung erfordert, sollten Sie die geplante Konnektivität für den Dienst beschreiben, einschließlich Netzwerkrouting, Proxykonfiguration, Paketüberprüfung und Bandbreitenanforderungen.
Für jeden Dienst, der eine eingehende Verbindung erfordert, benötigen Sie einige zusätzliche Informationen. Server in der Microsoft-Cloud stellen Verbindungen mit Ihrem lokalen Netzwerk her. Um sicherzustellen, dass die Verbindungen ordnungsgemäß hergestellt werden, sollten Sie alle Aspekte dieser Konnektivität beschreiben, einschließlich; die öffentlichen DNS-Einträge für die Dienste, die diese eingehenden Verbindungen akzeptieren, die CIDR-formatierten IPv4-IP-Adressen, welche ISP-Geräte beteiligt sind und wie eingehende NAT oder Quell-NAT für diese Verbindungen behandelt wird.
Eingehende Verbindungen sollten unabhängig davon überprüft werden, ob sie eine Verbindung über das Internet oder ExpressRoute herstellen, um sicherzustellen, dass asymmetrisches Routing nicht eingeführt wurde. In einigen Fällen muss auf lokale Endpunkte, mit denen Microsoft 365-Dienste eingehende Verbindungen initiieren, möglicherweise auch von anderen Microsoft- und Nicht-Microsoft-Diensten zugegriffen werden. Es ist von entscheidender Bedeutung, dass die Aktivierung des ExpressRoute-Routings zu diesen Diensten für Microsoft 365-Zwecke andere Szenarien nicht unterbricht. In vielen Fällen müssen Kunden möglicherweise bestimmte Änderungen an ihrem internen Netzwerk implementieren, z. B. eine quellbasierte NAT, um sicherzustellen, dass eingehende Datenflüsse von Microsoft nach der Aktivierung von ExpressRoute symmetrisch bleiben.
Im Folgenden finden Sie ein Beispiel für die erforderliche Detailebene. In diesem Fall wird Exchange Hybrid über ExpressRoute an das lokale System weitergeleitet.
| Connection-Eigenschaft | Wert |
|---|---|
| Richtung des Netzwerkdatenverkehrs |
Eingehend |
| Dienst |
Exchange Hybrid |
| Öffentlicher Microsoft 365-Endpunkt (Quelle) |
Exchange Online (IP-Adressen) |
| Öffentlicher lokaler Endpunkt (Ziel) |
5.5.5.5 |
| Öffentlicher DNS-Eintrag (Internet) |
Autodiscover.contoso.com |
| Wird dieser lokale Endpunkt für von anderen Microsoft-Diensten (nicht von Microsoft 365) verwendet? |
Nein |
| Wird dieser lokale Endpunkt von Benutzern/Systemen im Internet verwendet? |
Ja |
| Interne Systeme, die über öffentliche Endpunkte veröffentlicht werden |
Exchange Server Clientzugriffsrolle (lokal) 192.168.101, 192.168.102, 192.168.103 |
| IP-Ankündigung des öffentlichen Endpunkts |
Ins Internet: 5.5.0.0/16 zu ExpressRoute: 5.5.5.0/24 |
| Sicherheits-/Umkreissteuerungen |
Internetpfad: DeviceID_002 ExpressRoute-Pfad: DeviceID_003 |
| Hochverfügbarkeit |
Aktiv/Aktiv über 2 georedundante/ExpressRoute-Leitungen – Chicago und Dallas |
| Pfadsymmetriesteuerung |
Methode: Quell-NAT-Internetpfad: Eingehende NAT-Quellverbindungen mit 192.168.5.5 ExpressRoute-Pfad: Nat-Quellverbindungen zu 192.168.1.0 (Chicago) und 192.168.2.0 (Dallas) |
Hier sehen Sie ein Beispiel für einen Dienst, der nur ausgehend ist:
| Connection-Eigenschaft | Wert |
|---|---|
| Richtung des Netzwerkdatenverkehrs |
Ausgehend |
| Dienst |
SharePoint Online |
| Lokaler Endpunkt (Quelle) |
Benutzerarbeitsstation |
| Öffentlicher Microsoft 365-Endpunkt (Ziel) |
SharePoint Online (IP-Adressen) |
| Öffentlicher DNS-Eintrag (Internet) |
*.sharepoint.com (und mehr FQDNs) |
| CDN-Empfehlungen |
cdn.sharepointonline.com (und mehr FQDNs): IP-Adressen, die von CDN-Anbietern verwaltet werden) |
| IP-Ankündigung und NAT in Verwendung |
Internetpfad/Quell-NAT: 1.1.1.0/24 ExpressRoute-Pfad/Quell-NAT: 1.1.2.0/24 (Chicago) und 1.1.3.0/24 (Dallas) |
| Konnektivitätsmethode |
Internet: über Layer-7-Proxy (PAC-Datei) ExpressRoute: Direktes Routing (kein Proxy) |
| Sicherheits-/Umkreissteuerungen |
Internetpfad: DeviceID_002 ExpressRoute-Pfad: DeviceID_003 |
| Hochverfügbarkeit |
Internetpfad: Redundanter Internetausgang ExpressRoute-Pfad: Aktives/aktives "Hot Potato"-Routing über 2 georedundante ExpressRoute-Leitungen – Chicago und Dallas |
| Pfadsymmetriesteuerung |
Methode: Quell-NAT für alle Verbindungen |
Ihr Netzwerktopologieentwurf mit regionaler Konnektivität
Sobald Sie die Dienste und die zugehörigen Netzwerkdatenverkehrsflüsse verstanden haben, können Sie ein Netzwerkdiagramm erstellen, das diese neuen Konnektivitätsanforderungen berücksichtigt und die Änderungen veranschaulicht, die Sie bei der Verwendung von ExpressRoute für Microsoft 365 vornehmen. Ihr Diagramm sollte Folgendes enthalten:
Alle Benutzerstandorte, von denen aus auf Microsoft 365 und andere Dienste zugegriffen wird.
Alle Internet- und ExpressRoute-Ausgangspunkte.
Alle ausgehenden und eingehenden Geräte, die die Konnektivität ein- und aus dem Netzwerk verwalten, einschließlich Router, Firewalls, Anwendungsproxyserver und Angriffserkennung/-verhinderung.
Interne Ziele für den gesamten eingehenden Datenverkehr, z. B. interne AD FS-Server, die Verbindungen von den AD FS-Webanwendungsproxyservern akzeptieren.
Katalog aller IP-Subnetze, die angekündigt werden
Identifizieren Sie jeden Standort, von dem aus Personen auf Microsoft 365 zugreifen, und listen Sie die Meet-me-Standorte auf, die für ExpressRoute verwendet werden.
Standorte und Teile Ihrer internen Netzwerktopologie, in denen microsoft-IP-Präfixe, die von ExpressRoute gelernt wurden, akzeptiert, gefiltert und an weitergegeben werden.
Die Netzwerktopologie sollte den geografischen Standort jedes Netzwerksegments und die Verbindung mit dem Microsoft-Netzwerk über ExpressRoute und/oder das Internet veranschaulichen.
Das folgende Diagramm zeigt jeden Standort, von dem aus Personen Microsoft 365 verwenden, zusammen mit den Ein- und Ausgehenden Routing-Ankündigungen an Microsoft 365.
Für ausgehenden Datenverkehr greifen die Personen auf eine von drei Arten auf Microsoft 365 zu:
Durch einen Treffpunkt in Nordamerika für die Menschen in Kalifornien.
Durch einen Treffpunkt in der Sonderverwaltungsregion Hongkong für die Menschen in Hongkong SAR.
Über das Internet in Bangladesch, wo es weniger Menschen gibt und keine ExpressRoute-Leitung bereitgestellt wird.
Ebenso gibt der eingehende Netzwerkdatenverkehr von Microsoft 365 auf eine von drei Arten zurück:
Durch einen Treffpunkt in Nordamerika für die Menschen in Kalifornien.
Durch einen Treffpunkt in der Sonderverwaltungsregion Hongkong für die Menschen in Hongkong SAR.
Über das Internet in Bangladesch, wo es weniger Menschen gibt und keine ExpressRoute-Leitung bereitgestellt wird.
Ermitteln des geeigneten Treffpunkts
Die Auswahl der Meet-me-Standorte, d. h. der physische Standort, an dem Ihre ExpressRoute-Verbindung Ihr Netzwerk mit dem Microsoft-Netzwerk verbindet, wird von den Standorten beeinflusst, von denen aus Personen auf Microsoft 365 zugreifen. Als SaaS-Angebot wird Microsoft 365 nicht auf die gleiche Weise wie Azure unter dem regionalen IaaS- oder PaaS-Modell betrieben. Stattdessen ist Microsoft 365 eine verteilte Gruppe von Diensten für die Zusammenarbeit, bei denen Benutzer möglicherweise eine Verbindung mit Endpunkten in mehreren Rechenzentren und Regionen herstellen müssen, die sich möglicherweise nicht unbedingt an demselben Standort oder in derselben Region befinden, in dem der Mandant des Benutzers gehostet wird.
Dies bedeutet, dass die wichtigste Überlegung, die Sie bei der Auswahl von Besprechungsstandorten für ExpressRoute für Microsoft 365 treffen müssen, der Ort ist, von dem aus die Personen in Ihrem organization eine Verbindung herstellen. Die allgemeine Empfehlung für eine optimale Microsoft 365-Konnektivität ist das Implementieren von Routing, sodass Benutzeranforderungen an Microsoft 365-Dienste über den kürzesten Netzwerkpfad an das Microsoft-Netzwerk übergeben werden. Dies wird häufig auch als "Hot Potato"-Routing bezeichnet. Wenn sich z. B. die meisten Microsoft 365-Benutzer an einem oder zwei Standorten befinden, wird durch Auswählen von Meet-me-Standorten, die sich in der nähe des Standorts dieser Benutzer befinden, das optimale Design erstellt. Wenn Ihr Unternehmen über eine große Benutzerpopulation in vielen verschiedenen Regionen verfügt, sollten Sie mehrere ExpressRoute-Leitungen und Meet-me-Standorte in Betracht ziehen. Für einige Ihrer Benutzerstandorte ist der kürzeste/optimalste Weg zum Microsoft-Netzwerk und Microsoft 365 möglicherweise nicht über Ihre internen WAN- und ExpressRoute-Meet-me-Punkte, sondern über das Internet.
Häufig gibt es mehrere Besprechungsorte, die innerhalb einer Region mit relativer Nähe zu Ihren Benutzern ausgewählt werden können. Füllen Sie die folgende Tabelle aus, um Ihre Entscheidungen zu steuern.
Geplante ExpressRoute-Meet-me-Standorte in Kalifornien und New York
| Standort |
Personenzahl |
Erwartete Latenz für das Microsoft-Netzwerk über Internetausgang |
Erwartete Latenz für das Microsoft-Netzwerk über ExpressRoute |
|---|---|---|---|
| München |
10,000 |
~15 ms |
~10 ms (über Silicon Valley) |
| Washington DC |
15.000 |
~20 ms |
~10 ms (über New York) |
| Dallas |
5,000 |
~15 ms |
~40 ms (über New York) |
Sobald die globale Netzwerkarchitektur mit der Microsoft 365-Region, den ExpressRoute-Netzwerkdienstanbieter-Meet-me-Standorten und der Anzahl von Personen nach Standort entwickelt wurde, kann sie verwendet werden, um zu ermitteln, ob Optimierungen vorgenommen werden können. Es kann auch globale Haarnadelnetzwerkverbindungen anzeigen, bei denen der Datenverkehr zu einem entfernten Ort geleitet wird, um den Meet-me-Standort zu erhalten. Wenn eine Haarnadel im globalen Netzwerk entdeckt wird, sollte sie vor dem Fortfahren behoben werden. Suchen Sie entweder einen anderen Treffpunkt, oder verwenden Sie selektive Internet-Ausgangspunkte, um die Spitzkehre zu vermeiden.
Das erste Diagramm zeigt ein Beispiel für einen Kunden mit zwei physischen Standorten in Nordamerika. Sie können die Informationen zu Bürostandorten, Microsoft 365-Mandantenstandorten und verschiedene Optionen für ExpressRoute-Besprechungsstandorte anzeigen. In diesem Beispiel hat der Kunde den Meet-Me-Standort basierend auf zwei Prinzipien in der Reihenfolge ausgewählt:
Die nächstgelegene Nähe zu den Personen in ihrer organization.
In der Nähe eines Microsoft-Rechenzentrums, in dem Microsoft 365 gehostet wird.
Das zweite Diagramm, das dieses Konzept etwas erweitert, zeigt ein Beispiel für einen multinationalen Kunden, der mit ähnlichen Informationen und Entscheidungen konfrontiert ist. Dieser Kunde hat ein kleines Büro in Bangladesch mit nur einem kleinen Team von zehn Personen, das sich darauf konzentriert, seinen Fußabdruck in der Region zu erweitern. Es gibt einen Meet-Me-Standort in Chennai und ein Microsoft-Rechenzentrum mit Microsoft 365, das in Chennai gehostet wird, sodass ein Meet-Me-Standort sinnvoll wäre. für zehn Personen ist der Aufwand für die zusätzliche Leitung jedoch aufwendig. Wenn Sie sich Ihr Netzwerk ansehen, müssen Sie feststellen, ob die Latenz beim Senden ihres Netzwerkdatenverkehrs über Ihr Netzwerk effektiver ist, als das Kapital auszugeben, um eine andere ExpressRoute-Verbindung zu erwerben.
Alternativ können die zehn Personen in Bangladesch mit ihrem Netzwerkdatenverkehr, der über das Internet an das Microsoft-Netzwerk gesendet wird, eine bessere Leistung erzielen als das Routing über ihr internes Netzwerk, wie wir in den einführungsdiagrammen gezeigt und unten reproduziert haben.
Erstellen Ihres Implementierungsplans für ExpressRoute für Microsoft 365
Ihr Implementierungsplan sollte sowohl die technischen Details zum Konfigurieren von ExpressRoute als auch die Details zur Konfiguration aller anderen Infrastruktur in Ihrem Netzwerk umfassen, z. B. die folgenden.
Planen Sie, welche Dienste zwischen ExpressRoute und Internet aufgeteilt werden.
Planen Sie Bandbreite, Sicherheit, Hochverfügbarkeit und Failover.
Entwerfen des eingehenden und ausgehenden Routings, einschließlich geeigneter Routingpfadoptimierungen für verschiedene Standorte
Entscheiden Sie, wie weit ExpressRoute-Routen in Ihrem Netzwerk angekündigt werden und wie clients den Internet- oder ExpressRoute-Pfad auswählen können. z. B. Direct Routing oder Anwendungsproxy.
Planen Sie DNS-Eintragsänderungen, einschließlich Sender Policy Framework-Einträgen .
Planen Sie die NAT-Strategie, einschließlich ausgehender und eingehender Quell-NAT.
Planen Des Routings mit Internet- und ExpressRoute-Netzwerkpfaden
Für Ihre erste Bereitstellung wird empfohlen, dass alle eingehenden Dienste, z. B. eingehende E-Mails oder Hybridkonnektivität, das Internet verwenden.
Planen Sie das LAN-Routing des Endbenutzerclients, z. B . konfigurieren Sie eine PAC/WPAD-Datei, eine Standardroute, Proxyserver und BGP-Routenanzeigen.
Planen Sie das Umkreisrouting, einschließlich Proxyservern, Firewalls und Cloudproxys.
Planen Von Bandbreite, Sicherheit, Hochverfügbarkeit und Failover
Erstellen Sie einen Plan für die Bandbreite, die für jede Hauptworkload von Microsoft 365 erforderlich ist. Schätzen Sie die Bandbreitenanforderungen für Exchange Online, SharePoint Online und Skype for Business Online separat ab. Sie können die Schätzrechner verwenden, die wir für Exchange Online und Skype for Business als Ausgangspunkt bereitgestellt haben. Ein Pilottest mit einer repräsentativen Stichprobe der Benutzerprofile und Standorte ist jedoch erforderlich, um die Bandbreitenanforderungen Ihrer organization vollständig zu verstehen.
Fügen Sie Ihrem Plan hinzu, wie die Sicherheit an jedem Internet- und ExpressRoute-Ausgangsspeicherort behandelt wird. Denken Sie daran, dass alle ExpressRoute-Verbindungen mit Microsoft 365 öffentliches Peering verwenden und weiterhin in Übereinstimmung mit den Sicherheitsrichtlinien Ihres Unternehmens für die Verbindung mit externen Netzwerken geschützt werden müssen.
Fügen Sie Ihrem Plan Details dazu hinzu, welche Personen von welcher Art von Ausfall betroffen sind und wie diese Personen ihre Arbeit auf die einfachste Weise mit voller Kapazität ausführen können.
Planen der Bandbreitenanforderungen einschließlich Skype for Business Anforderungen an Jitter, Latenz, Überlastung und Spielraum
Skype for Business Online hat auch spezifische zusätzliche Netzwerkanforderungen, die im Artikel Medienqualität und Netzwerkkonnektivitätsleistung in Skype for Business Online beschrieben werden.
Lesen Sie den Abschnitt Bandbreitenplanung für Azure ExpressRoute. Wenn Sie eine Bandbreitenbewertung mit Ihren Pilotbenutzern durchführen, können Sie unseren Leitfaden zur Leistungsoptimierung von Microsoft 365 verwenden, indem Sie Baselines und den Leistungsverlauf verwenden.
Planen von Hochverfügbarkeitsanforderungen
Erstellen Sie einen Plan für Hochverfügbarkeit, um Ihre Anforderungen zu erfüllen, und integrieren Sie diesen in Ihr aktualisiertes Netzwerktopologiediagramm. Lesen Sie den Abschnitt Hochverfügbarkeit und Failover mit Azure ExpressRoute.
Planen der Netzwerksicherheitsanforderungen
Erstellen Sie einen Plan, um Ihre Netzwerksicherheitsanforderungen zu erfüllen, und integrieren Sie diesen in Ihr aktualisiertes Netzwerktopologiediagramm. Lesen Sie den Abschnitt Anwenden von Sicherheitskontrollen auf Azure ExpressRoute für Microsoft 365-Szenarien.
Entwerfen ausgehender Dienstkonnektivität
ExpressRoute für Microsoft 365 hat anforderungen an ausgehende Netzwerke, die möglicherweise nicht vertraut sind. Insbesondere müssen die IP-Adressen, die Ihre Benutzer und Netzwerke für Microsoft 365 darstellen und als Quellendpunkte für ausgehende Netzwerkverbindungen mit Microsoft fungieren, bestimmte Anforderungen erfüllen, die unten beschrieben werden.
Die Endpunkte müssen öffentliche IP-Adressen sein, die bei Ihrem Unternehmen oder für den Netzbetreiber registriert sind, der Ihnen ExpressRoute-Konnektivität bereitstellt.
Die Endpunkte müssen microsoft angekündigt und von ExpressRoute überprüft/akzeptiert werden.
Die Endpunkte dürfen nicht mit der gleichen oder einer bevorzugten Routingmetrik im Internet angekündigt werden.
Die Endpunkte dürfen nicht für die Konnektivität mit Microsoft-Diensten verwendet werden, die nicht über ExpressRoute konfiguriert sind.
Wenn Ihr Netzwerkentwurf diese Anforderungen nicht erfüllt, besteht ein hohes Risiko, dass Ihre Benutzer aufgrund von Black Holing oder asymmetrischem Routing Konnektivitätsfehler mit Microsoft 365 und anderen Microsoft-Diensten erleben. Dies tritt auf, wenn Anforderungen an Microsoft-Dienste über ExpressRoute weitergeleitet werden, antworten jedoch über das Internet oder umgekehrt zurückgeleitet werden und die Antworten von zustandsbehafteten Netzwerkgeräten wie Firewalls gelöscht werden.
Die gängigste Methode, die Sie verwenden können, um die oben genannten Anforderungen zu erfüllen, ist die Verwendung der Quell-NAT, die entweder als Teil Ihres Netzwerks implementiert oder von Ihrem ExpressRoute-Netzbetreiber bereitgestellt wird. Mit Source NAT können Sie die Details und die private IP-Adressierung Ihres Internetnetzwerks von ExpressRoute abstrahieren. in Verbindung mit ordnungsgemäßen IP-Routenanzeigen bieten sie einen einfachen Mechanismus, um die Pfadsymmetrie sicherzustellen. Wenn Sie zustandsbehaftete Netzwerkgeräte verwenden, die spezifisch für ExpressRoute-Peeringstandorte sind, müssen Sie separate NAT-Pools für jedes ExpressRoute-Peering implementieren, um die Pfadsymmetrie sicherzustellen.
Erfahren Sie mehr über die ExpressRoute NAT-Anforderungen.
Fügen Sie die Änderungen für die ausgehende Konnektivität zum Diagramm der Netzwerktopologie hinzu.
Entwerfen der eingehenden Dienstkonnektivität
Die meisten Microsoft 365-Unternehmensbereitstellungen setzen eine Art eingehender Konnektivität von Microsoft 365 mit lokalen Diensten voraus, z. B. für Exchange, SharePoint und Skype for Business Hybridszenarien, Postfachmigrationen und Authentifizierung mithilfe der AD FS-Infrastruktur. Wenn Sie expressRoute einen zusätzlichen Routingpfad zwischen Ihrem lokalen Netzwerk und Microsoft für ausgehende Verbindungen aktivieren, können diese eingehenden Verbindungen versehentlich durch asymmetrisches Routing beeinträchtigt werden, auch wenn Sie beabsichtigen, dass diese Flows weiterhin das Internet verwenden. Es werden einige der unten beschriebenen Vorsichtsmaßnahmen empfohlen, um sicherzustellen, dass es keine Auswirkungen auf internetbasierte eingehende Datenflüsse von Microsoft 365 zu lokalen Systemen gibt.
Um die Risiken des asymmetrischen Routings für eingehende Netzwerkdatenverkehrsflüsse zu minimieren, sollten alle eingehenden Verbindungen Quell-NAT verwenden, bevor sie in Segmente Ihres Netzwerks weitergeleitet werden, die über Routingsicht in ExpressRoute verfügen. Wenn die eingehenden Verbindungen in ein Netzwerksegment mit Routingsichtbarkeit in ExpressRoute ohne Quell-NAT zugelassen werden, werden Anforderungen von Microsoft 365 aus dem Internet gesendet, aber die Antwort, die an Microsoft 365 zurückgeht, bevorzugt den ExpressRoute-Netzwerkpfad zurück zum Microsoft-Netzwerk, was zu asymmetrischem Routing führt.
Sie können eines der folgenden Implementierungsmuster in Betracht ziehen, um diese Anforderung zu erfüllen:
Führen Sie die Quell-NAT aus, bevor Anforderungen mithilfe von Netzwerkgeräten wie Firewalls oder Lastenausgleichsmodulen auf dem Pfad vom Internet zu Ihren lokalen Systemen an Ihr internes Netzwerk weitergeleitet werden.
Stellen Sie sicher, dass ExpressRoute-Routen nicht an die Netzwerksegmente weitergegeben werden, in denen sich eingehende Dienste wie Front-End-Server oder Reverseproxysysteme befinden, die Internetverbindungen verarbeiten.
Die explizite Berücksichtigung dieser Szenarien in Ihrem Netzwerk und die Beibehaltung des gesamten eingehenden Netzwerkdatenverkehrs über das Internet trägt dazu bei, das Bereitstellungs- und Betriebsrisiko von asymmetrischem Routing zu minimieren.
Es kann vorkommen, dass Sie einige eingehende Datenflüsse über ExpressRoute-Verbindungen leiten möchten. Berücksichtigen Sie für diese Szenarien die folgenden zusätzlichen Überlegungen.
Microsoft 365 kann nur lokale Endpunkte als Ziel verwenden, die öffentliche IP-Adressen verwenden. Dies bedeutet, dass selbst wenn der lokale eingehende Endpunkt nur über ExpressRoute für Microsoft 365 verfügbar gemacht wird, diesem eine öffentliche IP-Adresse zugeordnet sein muss.
Alle DNS-Namensauflösungen, die Microsoft 365-Dienste ausführen, um lokale Endpunkte aufzulösen, werden mithilfe von öffentlichem DNS durchgeführt. Dies bedeutet, dass Sie den FQDN eingehender Dienstendpunkte für IP-Zuordnungen im Internet registrieren müssen.
Um eingehende Netzwerkverbindungen über ExpressRoute zu empfangen, müssen die öffentlichen IP-Subnetze für diese Endpunkte microsoft über ExpressRoute angekündigt werden.
Bewerten Sie diese eingehenden Netzwerkdatenverkehrsflüsse sorgfältig, um sicherzustellen, dass entsprechende Sicherheits- und Netzwerkkontrollen in Übereinstimmung mit den Sicherheits- und Netzwerkrichtlinien Ihres Unternehmens auf sie angewendet werden.
Sobald Ihre lokalen eingehenden Endpunkte für Microsoft über ExpressRoute angekündigt wurden, wird ExpressRoute effektiv zum bevorzugten Routingpfad zu diesen Endpunkten für alle Microsoft-Dienste, einschließlich Microsoft 365. Dies bedeutet, dass diese Endpunktsubnetze nur für die Kommunikation mit Microsoft 365-Diensten und keinen anderen Diensten im Microsoft-Netzwerk verwendet werden dürfen. Andernfalls führt Ihr Entwurf zu asymmetrischem Routing, bei dem eingehende Verbindungen von anderen Microsoft-Diensten es vorziehen, eingehende Verbindungen über ExpressRoute weiterzuleiten, während der Rückgabepfad das Internet verwendet.
Falls eine ExpressRoute-Verbindung oder ein Meet-Me-Standort ausgefallen ist, müssen Sie sicherstellen, dass die lokalen eingehenden Endpunkte weiterhin verfügbar sind, um Anforderungen über einen separaten Netzwerkpfad zu akzeptieren. Dies kann bedeuten, dass Subnetze für diese Endpunkte über mehrere ExpressRoute-Leitungen beworben werden.
Es wird empfohlen, die Quell-NAT für alle eingehenden Netzwerkdatenverkehrsflüsse anzuwenden, die über ExpressRoute in Ihr Netzwerk gelangen, insbesondere wenn diese Datenflüsse zustandsbehaftete Netzwerkgeräte wie Firewalls durchlaufen.
Einige lokale Dienste, z. B. ADFS-Proxy oder Exchange AutoErmittlung, empfangen möglicherweise eingehende Anforderungen sowohl von Microsoft 365-Diensten als auch von Benutzern aus dem Internet. Für diese Anforderungen zielt Microsoft 365 auf denselben FQDN wie Benutzeranforderungen über das Internet ab. Das Zulassen eingehender Benutzerverbindungen aus dem Internet zu diesen lokalen Endpunkten und gleichzeitig die Erzwingung von Microsoft 365-Verbindungen zur Verwendung von ExpressRoute stellt eine erhebliche Routingkomplexität dar. Für die überwiegende Mehrheit der Kunden, die solche komplexen Szenarien über ExpressRoute implementieren, wird aus betrieblichen Gründen nicht empfohlen. Dieser zusätzliche Mehraufwand umfasst das Verwalten von Risiken des asymmetrischen Routings und erfordert, dass Sie Routinganzeigen und -richtlinien über mehrere Dimensionen hinweg sorgfältig verwalten.
Aktualisieren Sie Ihren Netzwerktopologieplan, um zu zeigen, wie Sie asymmetrische Routen vermeiden würden.
Sie möchten asymmetrisches Routing vermeiden, um sicherzustellen, dass Personen in Ihrem organization Microsoft 365 und andere wichtige Dienste im Internet nahtlos nutzen können. Kunden haben zwei allgemeine Konfigurationen, die asymmetrisches Routing verursachen. Jetzt ist ein guter Zeitpunkt, um die Netzwerkkonfiguration zu überprüfen, die Sie verwenden möchten, und zu überprüfen, ob eines dieser asymmetrischen Routingszenarien vorhanden sein könnte.
Zunächst untersuchen wir einige verschiedene Situationen, die dem folgenden Netzwerkdiagramm zugeordnet sind. In diesem Diagramm befinden sich alle Server, die eingehende Anforderungen empfangen, z. B. AD FS oder lokale Hybridserver, im Rechenzentrum von New Jersey und werden im Internet angekündigt.
Obwohl das Umkreisnetzwerk sicher ist, ist keine Quell-NAT für eingehende Anforderungen verfügbar.
Die Server im Rechenzentrum von New Jersey können sowohl Internet- als auch ExpressRoute-Routen sehen.
Wir haben auch Vorschläge, wie sie behoben werden können.
Problem 1: Cloud-zu-Lokal-Verbindung über das Internet
Das folgende Diagramm veranschaulicht den asymmetrischen Netzwerkpfad, wenn Ihre Netzwerkkonfiguration keine NAT für eingehende Anforderungen aus der Microsoft-Cloud über das Internet bereitstellt.
Die eingehende Anforderung von Microsoft 365 ruft die IP-Adresse des lokalen Endpunkts aus dem öffentlichen DNS ab und sendet die Anforderung an Ihr Umkreisnetzwerk.
In dieser fehlerhaften Konfiguration ist im Umkreisnetzwerk, in dem der Datenverkehr gesendet wird, keine Quell-NAT konfiguriert oder verfügbar, was dazu führt, dass die tatsächliche Quell-IP-Adresse als Rückgabeziel verwendet wird.
Der Server in Ihrem Netzwerk leitet den zurückgegebenen Datenverkehr über eine beliebige verfügbare ExpressRoute-Netzwerkverbindung an Microsoft 365 weiter.
Das Ergebnis ist ein asymmetrischer Pfad für diesen Flow zu Microsoft 365, was zu einer unterbrochenen Verbindung führt.
Lösung 1a: Quell-NAT
Durch einfaches Hinzufügen einer Quell-NAT zur eingehenden Anforderung wird dieses falsch konfigurierte Netzwerk aufgelöst. Inhalt dieses Diagramms:
Die eingehende Anforderung wird weiterhin über das Umkreisnetzwerk des Rechenzentrums in New Jersey eingegeben. Dieses Mal ist Die Quell-NAT verfügbar.
Die Antwort vom Server wird an die IP-Adresse zurückgeleitet, die der Quell-NAT zugeordnet ist, anstatt an die ursprüngliche IP-Adresse, was dazu führt, dass die Antwort über denselben Netzwerkpfad zurückgegeben wird.
Lösung 1b: Routenbereich
Alternativ können Sie die Ankündigung der ExpressRoute-BGP-Präfixe nicht zulassen und den alternativen Netzwerkpfad für diese Computer entfernen. Inhalt dieses Diagramms:
Die eingehende Anforderung wird weiterhin über das Umkreisnetzwerk des Rechenzentrums in New Jersey eingegeben. Dieses Mal sind die von Microsoft über die ExpressRoute-Leitung angekündigten Präfixe für das Rechenzentrum in New Jersey nicht verfügbar.
Die Antwort vom Server wird über die einzige verfügbare Route zurück an die IP-Adresse weitergeleitet, die der ursprünglichen IP-Adresse zugeordnet ist, was dazu führt, dass die Antwort über denselben Netzwerkpfad zurückgegeben wird.
Problem 2: Cloud-zu-Lokal-Verbindung über ExpressRoute
Das folgende Diagramm veranschaulicht den asymmetrischen Netzwerkpfad, der verwendet wird, wenn Ihre Netzwerkkonfiguration keine NAT für eingehende Anforderungen aus der Microsoft-Cloud über ExpressRoute bereitstellt.
Die eingehende Anforderung von Microsoft 365 ruft die IP-Adresse vom DNS ab und sendet die Anforderung an Ihr Umkreisnetzwerk.
In dieser fehlerhaften Konfiguration ist im Umkreisnetzwerk, in dem der Datenverkehr gesendet wird, keine Quell-NAT konfiguriert oder verfügbar, was dazu führt, dass die tatsächliche Quell-IP-Adresse als Rückgabeziel verwendet wird.
Der Computer in Ihrem Netzwerk leitet den Zurücksendedatenverkehr über eine beliebige verfügbare ExpressRoute-Netzwerkverbindung an Microsoft 365 weiter.
Das Ergebnis ist eine asymmetrische Verbindung mit Microsoft 365.
Lösung 2: Quell-NAT
Durch einfaches Hinzufügen einer Quell-NAT zur eingehenden Anforderung wird dieses falsch konfigurierte Netzwerk aufgelöst. Inhalt dieses Diagramms:
Die eingehende Anforderung wird weiterhin über das Umkreisnetzwerk des New Yorker Rechenzentrums eingegeben. Dieses Mal ist Die Quell-NAT verfügbar.
Die Antwort vom Server wird an die IP-Adresse zurückgeleitet, die der Quell-NAT zugeordnet ist, anstatt an die ursprüngliche IP-Adresse, was dazu führt, dass die Antwort über denselben Netzwerkpfad zurückgegeben wird.
Papier: Überprüfen, ob der Netzwerkentwurf eine Pfadsymmetrie aufweist
An diesem Punkt müssen Sie auf Papier überprüfen, ob Ihr Implementierungsplan Routensymmetrie für die verschiedenen Szenarien bietet, in denen Sie Microsoft 365 verwenden werden. Sie identifizieren die spezifische Netzwerkroute, die erwartet wird, wenn eine Person verschiedene Features des Diensts verwendet. Vom lokalen Netzwerk und WAN-Routing zu den Umkreisgeräten bis zum Konnektivitätspfad; ExpressRoute oder das Internet und ein, um die Verbindung mit dem Onlineendpunkt herzustellen.
Sie müssen dies für alle Microsoft 365-Netzwerkdienste tun, die zuvor als Dienste identifiziert wurden, die Ihre organization übernehmen.
Es hilft, dieses Papier mit einer zweiten Person begehbaren Routen zu machen. Erläutern Sie ihnen, wo jeder Netzwerkhop seine nächste Route erhalten soll, und stellen Sie sicher, dass Sie mit den Routingpfaden vertraut sind. Denken Sie daran, dass ExpressRoute immer eine bereichsbezogenere Route zu Den IP-Adressen des Microsoft-Servers bereitstellt, was niedrigere Routenkosten als eine Standardroute des Internets bietet.
Entwerfen der Clientkonnektivitätskonfiguration
Wenn Sie einen Proxyserver für internetgebundenen Datenverkehr verwenden, müssen Sie alle PAC- oder Clientkonfigurationsdateien anpassen, um sicherzustellen, dass clientcomputer in Ihrem Netzwerk ordnungsgemäß so konfiguriert sind, dass sie den gewünschten ExpressRoute-Datenverkehr an Microsoft 365 senden, ohne Ihren Proxyserver zu übertragen, und der verbleibende Datenverkehr, einschließlich einiger Microsoft 365-Datenverkehr, wird an den entsprechenden Proxy gesendet. Lesen Sie unseren Leitfaden zum Verwalten von Microsoft 365-Endpunkten, z. B. PAC-Dateien.
Hinweis
Die Endpunkte ändern sich häufig, so oft wie wöchentlich. Sie sollten änderungen nur basierend auf den Diensten und Features vornehmen, die Ihr organization übernommen hat, um die Anzahl der Änderungen zu reduzieren, die Sie vornehmen müssen, um auf dem neuesten Stand zu bleiben. Achten Sie genau auf das Gültigkeitsdatum im RSS-Feed, an dem die Änderungen angekündigt werden und ein Datensatz über alle früheren Änderungen, IP-Adressen, die angekündigt werden, dürfen nicht angekündigt oder aus der Werbung entfernt werden, bis das Datum des Inkrafttretens erreicht ist.
Sicherstellen der Routensymmetrie
Auf die Microsoft 365-Front-End-Server kann sowohl über das Internet als auch über ExpressRoute zugegriffen werden. Diese Server ziehen es vor, über ExpressRoute-Leitungen zurück an die lokale Umgebung zu leiten, wenn beide verfügbar sind. Aus diesem Grund besteht die Möglichkeit einer Routenasymmetrie, wenn Datenverkehr aus Ihrem Netzwerk lieber über Ihre Internetverbindungen geleitet wird. Asymmetrische Routen sind ein Problem, da Geräte, die zustandsbehaftete Paketüberprüfungen durchführen, Rückgabedatenverkehr blockieren können, der einen anderen Pfad als die ausgehenden Pakete verfolgt.
Unabhängig davon, ob Sie eine Verbindung mit Microsoft 365 über das Internet oder ExpressRoute herstellen, muss die Quelle eine öffentlich routingfähige Adresse sein. Da viele Kunden ein direktes Peering mit Microsoft durchführen, ist es nicht möglich, private Adressen zu haben, bei denen Duplizierung zwischen Kunden möglich ist.
Im Folgenden finden Sie Szenarien, in denen die Kommunikation von Microsoft 365 mit Ihrem lokalen Netzwerk initiiert wird. Zur Vereinfachung Ihres Netzwerkentwurfs wird empfohlen, folgendes über den Internetpfad zu routingen.
SMTP-Dienste, z. B. E-Mails von einem Exchange Online Mandanten an einen lokalen Host oder SharePoint Online-E-Mail, die von SharePoint Online an einen lokalen Host gesendet werden. Das SMTP-Protokoll wird im Microsoft-Netzwerk breiter verwendet als die Routenpräfixe, die über ExpressRoute-Leitungen gemeinsam genutzt werden, und die Ankündigung lokaler SMTP-Server über ExpressRoute führt zu Fehlern mit diesen anderen Diensten.
AD FS während der Kennwortüberprüfung für die Anmeldung.
Skype for Business Hybrid- und/oder Skype for Business-Verbund.
Damit Microsoft für diese bidirektionalen Datenverkehrsflüsse zurück an Ihr Netzwerk weiterleiten kann, müssen die BGP-Routen zu Ihren lokalen Geräten mit Microsoft geteilt werden. Wenn Sie Routenpräfixe für Microsoft über ExpressRoute ankündigen, sollten Sie die folgenden bewährten Methoden befolgen:
Kündigen Sie nicht dasselbe Routenpräfix für öffentliche IP-Adressen im öffentlichen Internet und über ExpressRoute an. Es wird empfohlen, dass die IP-BGP-Routenpräfix-Ankündigungen an Microsoft über ExpressRoute aus einem Bereich stammen, der überhaupt nicht im Internet angekündigt wird. Wenn dies aufgrund des verfügbaren IP-Adressraums nicht möglich ist, müssen Sie sicherstellen, dass Sie einen spezifischeren Bereich über ExpressRoute als alle Internetleitungen ankündigen.
Verwenden Sie separate NAT-IP-Pools pro ExpressRoute-Verbindung und getrennt von denen Ihrer Internetleitungen.
Jede Route, die Microsoft angekündigt wird, zieht Netzwerkdatenverkehr von jedem Server im Microsoft-Netzwerk an, nicht nur von denen, für die Routen über ExpressRoute für Ihr Netzwerk angekündigt werden. Kündigen Sie Nur Routen an Server an, auf denen Routingszenarien definiert und von Ihrem Team gut verstanden werden. Kündigen Sie separate IP-Adressroutenpräfixe für jede von mehreren ExpressRoute-Verbindungen aus Ihrem Netzwerk an.
Hochverfügbarkeit und Failover mit Azure ExpressRoute
Es wird empfohlen, mindestens zwei aktive Verbindungen von jedem ausgehenden Datenverkehr mit ExpressRoute an Ihren ExpressRoute-Anbieter zu stellen. Dies ist der häufigste Ort, an dem Fehler für Kunden auftreten, und Sie können dies leicht vermeiden, indem Sie ein Paar von aktiven/aktiven ExpressRoute-Verbindungen bereitstellen. Wir empfehlen außerdem mindestens zwei aktive/aktive Internetleitungen, da viele Microsoft 365-Dienste nur über das Internet verfügbar sind.
Innerhalb des Ausgangspunkts Ihres Netzwerks befinden sich viele andere Geräte und Leitungen, die eine wichtige Rolle bei der Wahrnehmung der Verfügbarkeit spielen. Diese Teile Ihrer Konnektivitätsszenarien werden nicht von ExpressRoute oder Microsoft 365 SLAs abgedeckt, spielen aber eine wichtige Rolle bei der End-to-End-Dienstverfügbarkeit, wie sie von den Personen in Ihrem organization wahrgenommen wird.
Konzentrieren Sie sich auf die Personen, die Microsoft 365 verwenden und betreiben. Wenn ein Ausfall einer Komponente die Benutzerfreundlichkeit des Diensts beeinträchtigen würde, suchen Sie nach Möglichkeiten, den Gesamtprozentsatz der betroffenen Personen zu begrenzen. Wenn ein Failovermodus operativ komplex ist, sollten Sie die Erfahrung der Benutzer über eine lange Wiederherstellungszeit berücksichtigen und nach einfachen und automatisierten Failovermodi suchen.
Außerhalb Ihres Netzwerks verfügen Microsoft 365, ExpressRoute und Ihr ExpressRoute-Anbieter über unterschiedliche Verfügbarkeitsebenen.
Service Availability
Microsoft 365-Dienste werden durch klar definierte Vereinbarungen zum Servicelevel abgedeckt, die Betriebszeit- und Verfügbarkeitsmetriken für einzelne Dienste enthalten. Ein Grund, warum Microsoft 365 solch hohe Dienstverfügbarkeitsebenen aufrechterhalten kann, ist die Möglichkeit, dass einzelne Komponenten ein nahtloses Failover zwischen den vielen Microsoft-Rechenzentren mithilfe des globalen Microsoft-Netzwerks durchführen können. Dieses Failover erstreckt sich vom Rechenzentrum und Netzwerk bis zu mehreren Internetausgangspunkten und ermöglicht ein nahtloses Failover aus Sicht der Personen, die den Dienst verwenden.
ExpressRoute bietet eine SLA mit einer Verfügbarkeit von 99,9 % für einzelne dedizierte Leitungen zwischen Dem Microsoft Network Edge und dem ExpressRoute-Anbieter oder der Partnerinfrastruktur. Diese Servicelevel werden auf ExpressRoute-Leitungsebene angewendet, die aus zwei unabhängigen Verbindungen zwischen dem redundanten Microsoft-Gerät und dem Netzwerkanbietergerät an jedem Peeringstandort besteht.
Anbieterverfügbarkeit
- Die Vereinbarungen zum Servicelevel von Microsoft werden bei Ihrem ExpressRoute-Anbieter oder -Partner beendet. Dies ist auch der erste Ort, an dem Sie Entscheidungen treffen können, die Sich auf Ihre Verfügbarkeitsebene auswirken. Sie sollten die Architektur-, Verfügbarkeits- und Resilienzmerkmale, die Ihr ExpressRoute-Anbieter zwischen Ihrem Netzwerkperimeter und ihrer Anbieterverbindung an jedem Microsoft-Peeringstandort bietet, genau bewerten. Achten Sie sowohl auf die logischen als auch auf die physischen Aspekte der Redundanz, peering-Geräte, wan-Leitungen des Anbieters und alle zusätzlichen Mehrwertdienste wie NAT-Dienste oder verwaltete Firewalls.
Entwerfen Ihres Verfügbarkeitsplans
Es wird dringend empfohlen, Hochverfügbarkeit und Resilienz in Ihren End-to-End-Konnektivitätsszenarien für Microsoft 365 zu planen und zu entwerfen. Ein Entwurf sollte folgendes umfassen:
Keine Single Points of Failure, einschließlich Internet- und ExpressRoute-Leitungen.
Minimierung der Anzahl der betroffenen Personen und der Dauer dieser Auswirkung für die meisten erwarteten Fehlermodi.
Optimierung für einen einfachen, wiederholbaren und automatischen Wiederherstellungsprozess aus den meisten erwarteten Fehlermodi.
Unterstützung der vollständigen Anforderungen Ihres Netzwerkdatenverkehrs und Ihrer Funktionalität über redundante Pfade ohne erhebliche Beeinträchtigung.
Ihre Konnektivitätsszenarien sollten eine Netzwerktopologie enthalten, die für mehrere unabhängige und aktive Netzwerkpfade zu Microsoft 365 optimiert ist. Dies führt zu einer besseren End-to-End-Verfügbarkeit als eine Topologie, die nur für Redundanz auf der Ebene einzelner Geräte oder Geräte optimiert ist.
Tipp
Wenn Ihre Benutzer auf mehrere Kontinente oder geografische Regionen verteilt sind und jeder dieser Standorte über redundante WAN-Leitungen eine Verbindung mit einem einzelnen lokalen Standort herstellt, an dem sich eine einzelne ExpressRoute-Verbindung befindet, erhalten Ihre Benutzer weniger End-to-End-Dienstverfügbarkeit als bei einem Netzwerktopologieentwurf, der unabhängige ExpressRoute-Leitungen enthält, die die verschiedenen Regionen mit dem nächstgelegenen Peeringstandort verbinden.
Es wird empfohlen, mindestens zwei ExpressRoute-Verbindungen mit jeder Verbindung mit einem anderen geografischen Peeringstandort herzustellen. Sie sollten dieses Aktiv/Aktiv-Leitungspaar für jede Region bereitstellen, in der Personen ExpressRoute-Konnektivität für Microsoft 365-Dienste verwenden. Dadurch kann jede Region während eines Notfalls verbunden bleiben, der sich auf einen Hauptstandort auswirkt, z. B. ein Rechenzentrum oder einen Peeringstandort. Wenn Sie sie in als aktiv/aktiv konfigurieren, kann Der Endbenutzerdatenverkehr auf mehrere Netzwerkpfade verteilt werden. Dadurch wird der Umfang der Personen reduziert, die bei Ausfällen von Geräte- oder Netzwerkgeräten betroffen sind.
Es wird nicht empfohlen, eine einzelne ExpressRoute-Verbindung mit dem Internet als Sicherung zu verwenden.
Beispiel: Failover und Hochverfügbarkeit
Das multi-geografische Design von Contoso wurde einer Überprüfung des Routings, der Bandbreite und der Sicherheit unterzogen und muss nun eine Überprüfung der Hochverfügbarkeit durchlaufen. Contoso denkt über Hochverfügbarkeit, da sie drei Kategorien abdeckt. Resilienz, Zuverlässigkeit und Redundanz.
Resilienz ermöglicht contoso eine schnelle Wiederherstellung nach Fehlern. Mit der Zuverlässigkeit kann Contoso ein konsistentes Ergebnis innerhalb des Systems anbieten. Mit Redundanz kann Contoso zwischen einer oder mehreren gespiegelten Instanzen der Infrastruktur wechseln.
Innerhalb jeder Edgekonfiguration verfügt Contoso über redundante Firewalls, Proxys und IDS. Für Nordamerika verfügt Contoso über eine Edgekonfiguration im Rechenzentrum in Dallas und eine weitere edge-Konfiguration im Rechenzentrum in Virginia. Die redundanten Geräte an jedem Standort bieten Resilienz für diesen Standort.
Die Netzwerkkonfiguration bei Contoso basiert auf einigen wichtigen Prinzipien:
Innerhalb jeder geografischen Region gibt es mehrere Azure ExpressRoute-Verbindungen.
Jede Verbindung innerhalb einer Region kann den gesamten Netzwerkdatenverkehr innerhalb dieser Region unterstützen.
Das Routing bevorzugt eindeutig den einen oder den anderen Pfad, je nach Verfügbarkeit, Standort usw.
Das Failover zwischen Azure ExpressRoute-Leitungen erfolgt automatisch, ohne dass contoso zusätzliche Konfiguration oder Aktion erfordert.
Das Failover zwischen Internetleitungen erfolgt automatisch ohne zusätzliche Konfiguration oder Aktion, die von Contoso erforderlich ist.
In dieser Konfiguration ist Contoso mit Redundanz auf physischer und virtueller Ebene in der Lage, lokale Resilienz, regionale Resilienz und globale Resilienz auf zuverlässige Weise anzubieten. Contoso hat diese Konfiguration nach der Auswertung einer einzelnen Azure ExpressRoute-Verbindung pro Region sowie der Möglichkeit eines Failovers auf das Internet ausgewählt.
Wenn Contoso nicht über mehrere Azure ExpressRoute-Verbindungen pro Region verfügen kann, würde das Weiterleiten von Datenverkehr aus Nordamerika an die Azure ExpressRoute-Leitung in Asien-Pazifik zu einer inakzeptablen Latenz führen, und die erforderliche KONFIGURATION der DNS-Weiterleitung erhöht die Komplexität.
Die Verwendung des Internets als Sicherungskonfiguration wird nicht empfohlen. Dies verstößt gegen das Zuverlässigkeitsprinzip von Contoso, was zu einer inkonsistenten Verwendung der Verbindung führt. Darüber hinaus ist eine manuelle Konfiguration erforderlich, um ein Failover unter Berücksichtigung der konfigurierten BGP-Ankündigungen, der NAT-Konfiguration, der DNS-Konfiguration und der Proxykonfiguration zu erstellen. Diese zusätzliche Failoverkomplexität erhöht die Zeit für die Wiederherstellung und verringert die Fähigkeit, die erforderlichen Schritte zu diagnostizieren und zu behandeln.
Haben Sie noch Fragen zur Planung und Implementierung der Datenverkehrsverwaltung oder Azure ExpressRoute? Lesen Sie den Rest unseres Leitfadens zu Netzwerk und Leistung oder die häufig gestellten Fragen zu Azure ExpressRoute.
Anwenden von Sicherheitskontrollen auf Azure ExpressRoute für Microsoft 365-Szenarien
Das Schützen der Azure ExpressRoute-Konnektivität beginnt mit den gleichen Prinzipien wie die Sicherung der Internetkonnektivität. Viele Kunden entscheiden sich für die Bereitstellung von Netzwerk- und Umkreissteuerungen über den ExpressRoute-Pfad, der ihr lokales Netzwerk mit Microsoft 365 und anderen Microsoft-Clouds verbindet. Diese Kontrollen können Firewalls, Anwendungsproxys, Verhinderung von Datenlecks, Angriffserkennung, Intrusion Prevention-Systeme usw. umfassen. In vielen Fällen wenden Kunden unterschiedliche Steuerungsebenen auf Datenverkehr an, der von lokal an Microsoft initiiert wird, im Vergleich zu Datenverkehr, der von Microsoft in das lokale Kundennetzwerk initiiert wird, im Vergleich zu Datenverkehr, der von der lokalen Umgebung an ein allgemeines Internetziel initiiert wird.
Im Folgenden finden Sie einige Beispiele für die Integration der Sicherheit in das ExpressRoute-Konnektivitätsmodell , das Sie bereitstellen möchten.
| ExpressRoute-Integrationsoption | Netzwerksicherheitsperimetermodell |
|---|---|
| Colocated at an cloud exchange |
Installieren Sie eine neue Sicherheits-/Umkreisinfrastruktur in der Colocation-Einrichtung, in der die ExpressRoute-Verbindung hergestellt wird, oder verwenden Sie eine vorhandene Sicherheits-/Umkreisinfrastruktur. Verwenden Sie die Colocation-Einrichtung ausschließlich für Routing-/Verbindungszwecke, und ziehen Sie Verbindungen von der Colocation-Einrichtung in die lokale Sicherheits-/Umkreisinfrastruktur zurück. |
| Point-to-Point-Ethernet |
Beenden Sie die Point-to-Point-ExpressRoute-Verbindung am vorhandenen Standort der lokalen Sicherheits-/Umkreisinfrastruktur. Installieren Sie eine neue Sicherheits-/Umkreisinfrastruktur, die für den ExpressRoute-Pfad spezifisch ist, und beenden Sie dort die Point-to-Point-Verbindung. |
| Any-to-Any-IPVPN |
Verwenden Sie eine vorhandene lokale Sicherheits-/Umkreisinfrastruktur an allen Standorten, die in das IPVPN eingehen, das für ExpressRoute für Microsoft 365-Konnektivität verwendet wird. Heften Sie das IPVPN, das für ExpressRoute für Microsoft 365 verwendet wird, an bestimmte lokale Standorte, die als Sicherheit/Umkreis dienen sollen. |
Einige Dienstanbieter bieten auch verwaltete Sicherheits-/Umkreisfunktionen als Teil ihrer Integrationslösungen mit Azure ExpressRoute an.
Wenn Sie die Topologieplatzierung der Netzwerk-/Sicherheitsperimeteroptionen für ExpressRoute für Microsoft 365-Verbindungen in Betracht ziehen, sind folgende zusätzliche Überlegungen erforderlich.
Die Tiefen- und Typ-Netzwerk-/Sicherheitskontrollen können Auswirkungen auf die Leistung und Skalierbarkeit der Microsoft 365-Benutzeroberfläche haben.
Ausgehende (lokal-Microsoft>)- und eingehende (Microsoft-lokale>) Datenflüsse (sofern aktiviert) haben möglicherweise unterschiedliche Anforderungen. Diese unterscheiden sich wahrscheinlich von ausgehenden Internetzielen.
Die Microsoft 365-Anforderungen für Ports/Protokolle und die erforderlichen IP-Subnetze sind identisch, unabhängig davon, ob Datenverkehr über ExpressRoute für Microsoft 365 oder über das Internet weitergeleitet wird.
Die topologische Platzierung der Kundennetzwerk-/Sicherheitskontrollen bestimmt das end-to-End-Netzwerk zwischen dem Benutzer und dem Microsoft 365-Dienst und kann erhebliche Auswirkungen auf die Netzwerklatenz und -überlastung haben.
Kunden wird empfohlen, ihre Sicherheits-/Umkreistopologie für die Verwendung mit ExpressRoute für Microsoft 365 in Übereinstimmung mit bewährten Methoden für Redundanz, Hochverfügbarkeit und Notfallwiederherstellung zu entwerfen.
Hier sehen Sie ein Beispiel für Contoso, das die verschiedenen Azure ExpressRoute-Konnektivitätsoptionen mit den oben beschriebenen Umkreissicherheitsmodellen vergleicht.
Beispiel: Schützen von Azure ExpressRoute
Contoso erwägt die Implementierung von Azure ExpressRoute. Nachdem die optimale Architektur für ExpressRoute für Microsoft 365 geplant und die oben genannten Anleitungen zum Verständnis der Bandbreitenanforderungen verwendet wurden, wird die beste Methode zum Schützen des Umkreises ermittelt.
Für Contoso, eine multinationale organization mit Standorten auf mehreren Kontinenten, muss die Sicherheit alle Umkreise umfassen. Die optimale Konnektivitätsoption für Contoso ist eine Multi-Point-Verbindung mit mehreren Peeringstandorten auf der ganzen Welt, um die Anforderungen ihrer Mitarbeiter auf jedem Kontinent zu erfüllen. Jeder Kontinent umfasst redundante Azure ExpressRoute-Leitungen innerhalb des Kontinents, und die Sicherheit muss alle diese Umfassen umfassen.
Die vorhandene Infrastruktur von Contoso ist zuverlässig und kann den zusätzlichen Aufwand bewältigen. Dadurch kann Contoso die Infrastruktur für seine Azure ExpressRoute- und Internetperimetersicherheit nutzen. Wenn dies nicht der Fall wäre, könnte Contoso weitere Geräte erwerben, um die vorhandenen Geräte zu ergänzen oder eine andere Art von Verbindung zu verarbeiten.
Bandbreitenplanung für Azure ExpressRoute
Jeder Microsoft 365-Kunde hat spezifische Bandbreitenanforderungen, die von der Anzahl der Personen an jedem Standort, der Aktivität mit den einzelnen Microsoft 365-Anwendungen und anderen Faktoren wie der Verwendung von lokalen oder Hybridgeräten und Netzwerksicherheitskonfigurationen abhängen.
Eine zu geringe Bandbreite führt zu Überlastung, Neuübertragungen von Daten und unvorhersehbaren Verzögerungen. Eine zu hohe Bandbreite führt zu unnötigen Kosten. In einem vorhandenen Netzwerk wird die Bandbreite häufig in Bezug auf die Menge der verfügbaren Spielraum in der Verbindung als Prozentsatz bezeichnet. Eine 10%ige Kopffreiheit führt wahrscheinlich zu Überlastungen, und 80% Spielraum bedeutet im Allgemeinen unnötige Kosten. Typische Zielzuordnungen für die Kopfraumbelegung liegen bei 20 % bis 50 %.
Um die richtige Bandbreite zu finden, besteht der beste Mechanismus darin, Ihre vorhandene Netzwerknutzung zu testen. Dies ist die einzige Möglichkeit, ein echtes Maß an Nutzung und Bedarf zu erhalten, da jede Netzwerkkonfiguration und jede Anwendung in gewisser Weise einzigartig sind. Bei der Messung sollten Sie genau auf den Gesamten Bandbreitenverbrauch, die Latenz und die TCP-Überlastung achten, um Ihre Netzwerkanforderungen zu verstehen.
Sobald Sie über eine geschätzte Baseline verfügen, die alle Netzwerkanwendungen umfasst, führen Sie Microsoft 365 mit einer kleinen Gruppe aus, die die verschiedenen Profile von Personen in Ihrem organization umfasst, um die tatsächliche Nutzung zu bestimmen, und verwenden Sie die beiden Messungen, um die Bandbreite zu schätzen, die Sie für jeden Bürostandort benötigen. Wenn bei Ihren Tests Latenz- oder TCP-Überlastungsprobleme auftreten, müssen Sie den ausgehenden Datenverkehr möglicherweise näher an die Personen verschieben, die Microsoft 365 verwenden, oder intensive Netzwerküberprüfungen wie SSL-Entschlüsselung/-überprüfung entfernen.
Alle unsere Empfehlungen zur Art der empfohlenen Netzwerkverarbeitung gelten sowohl für ExpressRoute- als auch für Internetleitungen. Dies gilt auch für den Rest der Anleitungen auf unserer Website zur Leistungsoptimierung.
Erstellen Ihrer Bereitstellungs- und Testprozeduren
Ihr Implementierungsplan sollte sowohl die Test- als auch die Rollbackplanung umfassen. Wenn Ihre Implementierung nicht wie erwartet funktioniert, sollte der Plan so konzipiert sein, dass er sich auf die geringste Anzahl von Personen auswirkt, bevor Probleme erkannt werden. Im Folgenden sind einige allgemeine Prinzipien aufgeführt, die Ihr Plan berücksichtigen sollte.
Stufen Sie das Onboarding des Netzwerksegments und des Benutzerdiensts auf, um Unterbrechungen zu minimieren.
Planen Sie das Testen von Routen mit Traceroute und TCP-Verbindung von einem separaten Host mit Internetverbindung.
Vorzugsweise sollten tests von ein- und ausgehenden Diensten in einem isolierten Testnetzwerk mit einem Microsoft 365-Testmandanten durchgeführt werden.
Alternativ können Tests in einem Produktionsnetzwerk durchgeführt werden, wenn der Kunde Microsoft 365 noch nicht verwendet oder sich in einem Pilotprojekt befindet.
Alternativ können Tests während eines Produktionsausfalls durchgeführt werden, der nur für Tests und Überwachung vorgesehen ist.
Alternativ können Tests durchgeführt werden, indem Die Routen für jeden Dienst auf jedem Routerknoten der Ebene 3 überprüft werden. Dieses Fallback sollte nur verwendet werden, wenn keine anderen Tests möglich sind, da ein Mangel an physischen Tests ein Risiko darstellt.
Erstellen Ihrer Bereitstellungsverfahren
Ihre Bereitstellungsverfahren sollten schrittweise für kleine Gruppen von Personen bereitgestellt werden, um Tests zu ermöglichen, bevor sie für größere Personengruppen bereitgestellt werden. Im Folgenden finden Sie mehrere Möglichkeiten, um die Bereitstellung von ExpressRoute zu stufen.
Richten Sie ExpressRoute mit Microsoft-Peering ein, und lassen Sie die Routenanzeigen nur zu mehrstufigen Testzwecken an einen einzelnen Host weiterleiten.
Angekündigte Routen für das ExpressRoute-Netzwerk zunächst für ein einzelnes Netzwerksegment und Erweitern der Routenanzeigen nach Netzwerksegment oder Region.
Wenn Sie Microsoft 365 zum ersten Mal bereitstellen, verwenden Sie die ExpressRoute-Netzwerkbereitstellung als Pilotprojekt für einige Personen.
Wenn Sie Proxyserver verwenden, können Sie alternativ eine PAC-Testdatei konfigurieren, um einige Personen mit Tests und Feedback an ExpressRoute weiterzuleiten, bevor Sie weitere hinzufügen.
Ihr Implementierungsplan sollte alle Bereitstellungsverfahren, die ausgeführt werden müssen, oder Befehle auflisten, die zum Bereitstellen der Netzwerkkonfiguration verwendet werden müssen. Wenn die Netzwerkausfallzeit eintrifft, sollten alle vorgenommenen Änderungen aus dem schriftlichen Bereitstellungsplan stammen, der im Voraus geschrieben und vom Peer überprüft wurde. Weitere Informationen finden Sie in unserem Leitfaden zur technischen Konfiguration von ExpressRoute.
Aktualisieren Sie Ihre SPF TXT-Einträge, wenn Sie die IP-Adressen für lokale Server geändert haben, die weiterhin E-Mails senden.
Aktualisieren aller DNS-Einträge für lokale Server, wenn Sie IP-Adressen geändert haben, um eine neue NAT-Konfiguration zu ermöglichen.
Stellen Sie sicher, dass Sie den RSS-Feed für Microsoft 365-Endpunktbenachrichtigungen abonniert haben, um Routing- oder Proxykonfigurationen beizubehalten.
Nach Abschluss der ExpressRoute-Bereitstellung sollten die Verfahren im Testplan ausgeführt werden. Die Ergebnisse für jede Prozedur sollten protokolliert werden. Sie müssen Verfahren für das Rollback zur ursprünglichen Produktionsumgebung einschließen, falls die Testplanergebnisse darauf hindeuten, dass die Implementierung nicht erfolgreich war.
Erstellen Ihrer Testprozeduren
Ihre Testverfahren sollten Tests für jeden ausgehenden und eingehenden Netzwerkdienst für Microsoft 365 enthalten, der ExpressRoute verwendet und nicht. Die Verfahren sollten Tests von jedem eindeutigen Netzwerkstandort umfassen, einschließlich Benutzern, die sich nicht lokal im Unternehmens-LAN befinden.
Einige Beispiele für Testaktivitäten sind die folgenden:
Pingen Sie von Ihrem lokalen Router an den Router Ihres Netzbetreibers.
Überprüfen Sie, ob die Ip-Adressanzeigen von Microsoft 365 und CRM Online über 500 von Ihrem lokalen Router empfangen werden.
Überprüfen Sie, ob Ihre eingehende und ausgehende NAT zwischen ExpressRoute und dem internen Netzwerk funktioniert.
Überprüfen Sie, ob Routen zu Ihrer NAT von Ihrem Router angekündigt werden.
Überprüfen Sie, ob ExpressRoute Ihre angekündigten Präfixe akzeptiert hat.
- Verwenden Sie das folgende Cmdlet, um Peering-Ankündigungen zu überprüfen:
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeeringÜberprüfen Sie, ob Ihr öffentlicher NAT-IP-Adressbereich microsoft nicht über eine andere ExpressRoute- oder öffentliche Internetnetzwerkverbindung angekündigt wird, es sei denn, es handelt sich um eine bestimmte Teilmenge eines größeren Bereichs wie im vorherigen Beispiel.
ExpressRoute-Verbindungen sind gekoppelt. Überprüfen Sie, ob beide BGP-Sitzungen ausgeführt werden.
Richten Sie einen einzelnen Host innerhalb Ihrer NAT ein, und verwenden Sie Ping, Tracert und tcpping, um die Konnektivität über die neue Verbindung mit dem Host outlook.office365.com zu testen. Alternativ können Sie ein Tool wie Wireshark oder Microsoft Network Monitor 3.4 auf einem gespiegelten Port zum MSEE verwenden, um zu überprüfen, ob Sie eine Verbindung mit der IP-Adresse herstellen können, die outlook.office365.com zugeordnet ist.
Testen Sie die Funktionalität auf Anwendungsebene für Exchange Online.
Testen Sie, dass Outlook eine Verbindung mit Exchange Online herstellen und E-Mails senden/empfangen kann.
Testen Sie, dass Outlook den Onlinemodus verwenden kann.
Testen Sie die Smartphone-Konnektivität und die Sende-/Empfangsfunktion.
- Testen der Funktionalität auf Anwendungsebene für SharePoint Online
Testen OneDrive for Business Synchronisierungsclients.
Testen des SharePoint Online-Webzugriffs.
- Testen Sie die Funktionalität auf Anwendungsebene für Skype for Business Anrufszenarien:
Nehmen Sie als authentifizierter Benutzer an einer Telefonkonferenz teil [Einladung wurde vom Endbenutzer initiiert].
Laden Sie den Benutzer zur Telefonkonferenz [Einladung von MCU gesendet] ein.
Nehmen Sie mit der Skype for Business Webanwendung als anonymer Benutzer an der Konferenz teil.
Nehmen Sie an Einem Anruf über Ihre kabelgebundene PC-Verbindung, ihr IP-Telefon und Ihr mobiles Gerät teil.
Anruf an Verbundbenutzer o Anruf an PSTN-Überprüfung: Der Anruf ist abgeschlossen, die Anrufqualität ist akzeptabel, die Verbindungszeit ist akzeptabel.
Überprüfen Sie, ob die Anwesenheit status für Kontakte sowohl für Mitglieder des Mandanten als auch für Verbundbenutzer aktualisiert wird.
Häufig auftretende Probleme
Asymmetrisches Routing ist das häufigste Implementierungsproblem. Im Folgenden finden Sie einige gängige Quellen, nach denen Sie suchen können:
Verwenden einer offenen oder flachen Netzwerkroutingtopologie ohne Quell-NAT.
Keine Verwendung von SNAT zum Weiterleiten an eingehende Dienste sowohl über das Internet als auch über ExpressRoute-Verbindungen.
Testen Sie eingehende Dienste nicht in ExpressRoute in einem Testnetzwerk, bevor sie allgemein bereitgestellt werden.
Bereitstellen von ExpressRoute-Konnektivität über Ihr Netzwerk
Stufen Sie Ihre Bereitstellung auf jeweils ein Segment des Netzwerks auf, und führen Sie die Konnektivität schrittweise mit verschiedenen Teilen des Netzwerks ein, wobei ein Rollback für jedes neue Netzwerksegment geplant ist. Wenn Ihre Bereitstellung an einer Microsoft 365-Bereitstellung ausgerichtet ist, stellen Sie zuerst für Ihre Microsoft 365-Pilotbenutzer bereit, und erweitern Sie sie von dort aus.
Zuerst für Ihren Test und dann für die Produktion:
Führen Sie die Bereitstellungsschritte aus, um ExpressRoute zu aktivieren.
Testen Sie, dass die Netzwerkrouten wie erwartet funktionieren.
Führen Sie Tests für jeden eingehenden und ausgehenden Dienst durch.
Rollback, wenn Sie Probleme feststellen.
Einrichten einer Testverbindung mit ExpressRoute mit einem Testnetzwerksegment
Da Sie nun den abgeschlossenen Plan auf Papier haben, ist es an der Zeit, in einem kleinen Maßstab zu testen. In diesem Test stellen Sie eine einzelne ExpressRoute-Verbindung mit Microsoft-Peering mit einem Testsubnetz in Ihrem lokalen Netzwerk her. Sie können einen Microsoft 365-Testmandanten mit Konnektivität mit und aus dem Testsubnetz konfigurieren und alle ausgehenden und eingehenden Dienste einschließen, die Sie in der Produktion im Testsubnetz verwenden. Richten Sie DNS für das Testnetzwerksegment ein, und richten Sie alle ein- und ausgehenden Dienste ein. Führen Sie Ihren Testplan aus, und stellen Sie sicher, dass Sie mit dem Routing für jeden Dienst und der Routenweitergabe vertraut sind.
Ausführen der Bereitstellungs- und Testpläne
Wenn Sie die oben beschriebenen Elemente ausführen, überprüfen Sie die bereiche, die Sie abgeschlossen haben, und stellen Sie sicher, dass Sie und Ihr Team diese überprüft haben, bevor Sie Ihre Bereitstellungs- und Testpläne ausführen.
Liste der ausgehenden und eingehenden Dienste, die an der Netzwerkänderung beteiligt sind.
Diagramm der globalen Netzwerkarchitektur, das sowohl ausgehende Internet- als auch ExpressRoute-Meet-me-Standorte zeigt.
Diagramm zum Netzwerkrouting, das die verschiedenen Netzwerkpfade zeigt, die für jeden bereitgestellten Dienst verwendet werden.
Ein Bereitstellungsplan mit Schritten zum Implementieren der Änderungen und ggf. rollback.
Ein Testplan zum Testen der einzelnen Microsoft 365- und Netzwerkdienste.
Abgeschlossene Papiervalidierung der Produktionsrouten für ein- und ausgehende Dienste.
Ein abgeschlossener Test in einem Testnetzwerksegment, einschließlich Verfügbarkeitstests.
Wählen Sie ein Ausfallfenster aus, das lang genug ist, um den gesamten Bereitstellungsplan und den Testplan zu durchlaufen, der einige Zeit für die Problembehandlung und bei Bedarf zeit für das Rollback hat.
Achtung
Aufgrund der komplexen Art des Routings sowohl über das Internet als auch über ExpressRoute wird empfohlen, diesem Fenster zusätzliche Pufferzeit hinzuzufügen, um die Problembehandlung bei komplexem Routing zu bewältigen.
Konfigurieren von QoS für Skype for Business Online
QoS ist erforderlich, um Sprach- und Besprechungsvorteile für Skype for Business Online zu erhalten. Sie können QoS konfigurieren, nachdem Sie sichergestellt haben, dass die ExpressRoute-Netzwerkverbindung keinen Anderen Microsoft 365-Dienstzugriff blockiert. Die Konfiguration für QoS wird im Artikel ExpressRoute und QoS in Skype for Business Online beschrieben.
Problembehandlung für Ihre Implementierung
Sehen Sie sich zunächst die Schritte in diesem Implementierungsleitfaden an. Wurden in Ihrem Implementierungsplan verpasst? Zurück und führen Sie nach Möglichkeit weitere kleine Netzwerktests aus, um den Fehler zu replizieren und dort zu debuggen.
Identifizieren Sie, welche eingehenden oder ausgehenden Dienste während des Tests fehlgeschlagen sind. Rufen Sie speziell die IP-Adressen und Subnetze für die einzelnen Dienste ab, bei denen ein Fehler aufgetreten ist. Gehen Sie fort, und führen Sie das Diagramm der Netzwerktopologie auf Papier aus, und überprüfen Sie das Routing. Überprüfen Sie genau, wo das ExpressRoute-Routing angekündigt wird, und testen Sie dieses Routing während des Ausfalls nach Möglichkeit mit Ablaufverfolgungen.
Führen Sie PSPing mit einer Netzwerkablaufverfolgung für jeden Kundenendpunkt aus, und werten Sie Quell- und Ziel-IP-Adressen aus, um zu überprüfen, ob sie erwartungsgemäß sind. Führen Sie telnet auf einem beliebigen E-Mail-Host aus, den Sie an Port 25 verfügbar machen, und vergewissern Sie sich, dass SNAT die ursprüngliche Quell-IP-Adresse ausblendet, wenn dies erwartet wird.
Beachten Sie, dass Sie bei der Bereitstellung von Microsoft 365 mit einer ExpressRoute-Verbindung sicherstellen müssen, dass sowohl die Netzwerkkonfiguration für ExpressRoute optimal konzipiert ist als auch die anderen Komponenten in Ihrem Netzwerk wie Clientcomputer optimiert haben. Zusätzlich zur Verwendung dieses Planungsleitfadens zur Problembehandlung der Möglicherweise verpassten Schritte haben wir auch einen Leistungsplan zur Problembehandlung für Microsoft 365 geschrieben.
Mit diesem kurzen Link gelangen Sie wieder hierher zurück: https://aka.ms/implementexpressroute365
Verwandte Themen
Bewerten der Microsoft 365-Netzwerkkonnektivität
Azure ExpressRoute für Microsoft 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
Microsoft 365-Leistungsoptimierung mithilfe von Baselines und Leistungsverlauf
Leistungsproblembehandlungsplan für Microsoft 365
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für