ExpressRoute-Routinganforderungen

Zum Herstellen einer Verbindung mit Microsoft-Clouddiensten per ExpressRoute müssen Sie das Routing einrichten und verwalten. Einige Konnektivitätsanbieter bieten das Einrichten und Verwalten des Routings als verwalteten Dienst an. Fragen Sie bei Ihrem Konnektivitätsanbieter nach, ob dieser Dienst angeboten wird. Ist dies nicht der Fall, müssen Sie folgende Anforderungen erfüllen:

Der Artikel ExpressRoute-Verbindungen und Routingdomänen enthält eine Beschreibung der Routingsitzungen, die zum Herstellen der Konnektivität eingerichtet werden müssen.

IP-Adressen für Peering

Sie müssen einige Blöcke mit IP-Adressen reservieren, um das Routing zwischen Ihrem Netzwerk und den Microsoft Enterprise-Edgeroutern (MSEEs) zu konfigurieren. Dieser Abschnitt enthält eine Liste mit den Anforderungen, und es werden die Regeln zur Beschaffung und Verwendung dieser IP-Adressen beschrieben.

IP-Adressen für privates Azure-Peering

Sie können entweder private IP-Adressen oder öffentliche IP-Adressen verwenden, um das Peering zu konfigurieren. Der Adressbereich zum Konfigurieren der Routen kann sich nicht mit Adressbereichen überlappen, die für virtuelle Netzwerke in Azure verwendet werden.

• IPv4:
  • Sie müssen ein /29-Subnetz oder zwei /30-Subnetze für Routingschnittstellen reservieren.
  • Die für das Routing verwendeten Subnetze können entweder private IP-Adressen oder öffentliche IP-Adressen sein.
  • Die Subnetze dürfen nicht mit dem Bereich in Konflikt stehen, der vom Kunden für die Nutzung in der Microsoft Cloud reserviert ist.
  • Wenn ein /29-Subnetz verwendet wird, wird es in zwei /30-Subnetze unterteilt.
    • Das erste /30-Subnetz wird für die primäre Verknüpfung verwendet, das zweite /30-Subnetz für die sekundäre Verknüpfung.
    • Für jedes /30-Subnetz müssen Sie die erste IP-Adresse des /30-Subnetzes für den Router verwenden. Microsoft verwendet die zweite IP-Adresse des /30-Subnetzes zum Einrichten einer BGP-Sitzung.
    • Sie müssen beide BGP-Sitzungen einrichten, damit die Vereinbarungen zum Servicelevel gültig sind.
• IPv6:
  • Sie müssen ein /125-Subnetz oder zwei /126-Subnetze für Routingschnittstellen reservieren.
  • Die für das Routing verwendeten Subnetze können entweder private IP-Adressen oder öffentliche IP-Adressen sein.
  • Die Subnetze dürfen nicht mit dem Bereich in Konflikt stehen, der vom Kunden für die Nutzung in der Microsoft Cloud reserviert ist.
  • Wenn ein /125-Subnetz verwendet wird, wird es in zwei /126-Subnetze unterteilt.
    • Das erste /126-Subnetz wird für die primäre Verknüpfung verwendet, das zweite /126-Subnetz für die sekundäre Verknüpfung.
    • Für jedes /126-Subnetz müssen Sie die erste IP-Adresse des /126-Subnetzes für den Router verwenden. Microsoft verwendet die zweite IP-Adresse des /126-Subnetzes zum Einrichten einer BGP-Sitzung.
    • Sie müssen beide BGP-Sitzungen einrichten, damit die Vereinbarungen zum Servicelevel gültig sind.

Beispiel für privates Peering

Wenn Sie zum Einrichten des Peerings a.b.c.d/29 verwenden, wird eine Unterteilung in zwei /30-Subnetze vorgenommen. Beachten Sie im folgenden Beispiel, wie das Subnetz a.b.c.d/29 verwendet wird:

• a.b.c.d/29 wird in a.b.c.d/30 und a.b.c.d+4/30 unterteilt und über die Bereitstellungs-APIs an Microsoft übergeben.
  • Sie verwenden a.b.c.d+1 als VRF-IP für das primäre PE-Element, und Microsoft verwendet a.b.c.d+2 als VRF-IP für den primären MSEE.
  • Sie verwenden a.b.c.d+5 als VRF-IP für das sekundäre PE-Element, und Microsoft verwendet a.b.c.d+6 als VRF-IP für den sekundären MSEE.

Betrachten wir den Fall, in dem Sie 192.168.100.128/29 zum Einrichten des privaten Peerings auswählen. 192.168.100.128/29 enthält die Adressen von 192.168.100.128 bis 192.168.100.135, für die Folgendes gilt:

• 192.168.100.128/30 wird link1 zugewiesen, wobei der Anbieter 192.168.100.129 und Microsoft 192.168.100.130 verwendet.
• 192.168.100.132/30 wird link2 zugewiesen, wobei der Anbieter 192.168.100.133 und Microsoft 192.168.100.134 verwendet.

IP-Adressen für Microsoft-Peering

Sie müssen eigene öffentliche IP-Adressen zum Einrichten der BGP-Sitzungen verwenden. Microsoft muss in der Lage sein, die Eigentümerschaft der IP-Adressen über Routing Internet Registries (RIR) und Internet Routing Registries (IRR) zu überprüfen.

• Die im Portal für angekündigte öffentliche Präfixe aufgeführten IP-Adressen für Microsoft-Peering erstellen ACLs für die Microsoft-Kernrouter, um eingehenden Datenverkehr von diesen IP-Adressen zuzulassen.
• Sie müssen ein eindeutiges /29-Subnetz (IPv4) oder /125-Subnetz (IPv6) oder zwei /30-Subnetze (IPv4) oder zwei /126-Subnetze (IPv6) verwenden, um das BGP-Peering für jedes Peering pro ExpressRoute-Verbindung einzurichten, falls Sie über mehrere verfügen.
• Wenn ein /29-Subnetz verwendet wird, wird es in zwei /30-Subnetze unterteilt.
• Das erste /30-Subnetz wird für die primäre Verknüpfung verwendet, das zweite /30-Subnetz für die sekundäre Verknüpfung.
• Für jedes /30-Subnetz müssen Sie die erste IP-Adresse des /30-Subnetzes auf dem Router verwenden. Microsoft verwendet die zweite IP-Adresse des /30-Subnetzes zum Einrichten einer BGP-Sitzung.
• Wenn ein /125-Subnetz verwendet wird, wird es in zwei /126-Subnetze unterteilt.
• Das erste /126-Subnetz wird für die primäre Verknüpfung verwendet, das zweite /126-Subnetz für die sekundäre Verknüpfung.
• Für jedes /126-Subnetz müssen Sie die erste IP-Adresse des /126-Subnetzes auf dem Router verwenden. Microsoft verwendet die zweite IP-Adresse des /126-Subnetzes zum Einrichten einer BGP-Sitzung.
• Sie müssen beide BGP-Sitzungen einrichten, damit unsere Vereinbarungen zum Servicelevel gültig sind.

Öffentliche IP-Adresse – Anforderungen

Privates Peering

Sie können für das private Peering öffentliche oder private IPv4-Adressen verwenden. Wir stellen eine End-to-End-Isolation für Ihren Datenverkehr bereit, sodass für privates Peering keine Überlappungen von Adressen mit anderen Kunden möglich sind. Diese Adressen werden nicht im Internet angekündigt.

Microsoft-Peering

Über den Microsoft-Peeringpfad können Sie eine Verbindung mit Microsoft-Clouddiensten herstellen. Die Liste der Dienste umfasst Microsoft 365-Dienste wie z.B. Exchange Online, SharePoint Online, Skype for Business und Microsoft Teams. Microsoft unterstützt die bidirektionale Konnektivität für das Microsoft-Peering. Für Datenverkehr, der für Microsoft-Clouddienste bestimmt ist, müssen vor dem Eintritt in das Microsoft-Netzwerk gültige, öffentliche IPv4-Adressen verwendet werden.

Stellen Sie sicher, dass Ihre IP-Adresse und die AS-Nummer für Sie in einer der folgenden Registrierungen registriert sind:

• ARIN
• APNIC
• AFRINIC
• LACNIC
• RIPENCC
• RADB
• ALTDB

Falls Ihre Präfixe und Ihre AS-Nummer in den obigen Registrierungen nicht Ihnen zugewiesen sind, müssen Sie eine Supportanfrage zur manuellen Überprüfung Ihrer Präfixe und ASN stellen. Dazu benötigt der Support Belege – beispielsweise ein Autorisierungsschreiben, das beweist, dass Sie zur Verwendung dieses Präfix berechtigt sind.

Für Microsoft-Peering kann eine private AS-Nummer verwendet werden, dies erfordert jedoch ebenfalls eine manuelle Überprüfung. Darüber hinaus entfernen wir private AS-Nummern in „AS PATH“ für die empfangenen Präfixe. Dadurch können Sie in „AS PATH“ keine privaten AS-Nummern anfügen, um das Routing für Microsoft-Peering zu beeinflussen. Außerdem sind die von IANA für Dokumentationszwecke reservierten AS-Nummern 64496–64511 im Pfad nicht zulässig.

Dynamischer Routenaustausch

Der Routingaustausch verläuft über das eBGP-Protokoll. EBGP-Sitzungen werden zwischen den MSEEs und Ihren Routern eingerichtet. Die Authentifizierung von BGP-Sitzungen ist nicht unbedingt erforderlich. Bei Bedarf kann ein MD5-Hash konfiguriert werden. Unter Konfigurieren des Routings und Bereitstellungsworkflows für ExpressRoute-Verbindungen und Verbindungszustände finden Sie Informationen zum Konfigurieren von BGP-Sitzungen.

Autonome Systemnummern (ASN)

Microsoft verwendet AS 12076 für öffentliches und privates Azure-Peering sowie für Microsoft-Peering. Wir haben ASNs von 65515 bis 65520 für die interne Verwendung reserviert. Sowohl AS-Nummern mit 16 Bit als auch mit 32 Bit werden unterstützt.

Es gibt keine Anforderungen in Bezug auf die Symmetrie der Datenübertragung. Die Weiterleitungs- und Rückgabepfade können unterschiedliche Routerpaare durchlaufen. Identische Routen müssen von beiden Seiten über mehrere Verbindungspaare angekündigt werden, die in Ihrem Besitz sind. Routenmetriken müssen nicht identisch sein.

Routenaggregation- und Präfixgrenzen

ExpressRoute unterstützt bis zu 4000 IPv4-Präfixe und 100 IPv6-Präfixe, die Microsoft per privatem Azure-Peering angekündigt wurden. Dieser Grenzwert kann auf bis zu 10.000 IPv4-Präfixe erhöht werden, wenn das ExpressRoute Premium-Add-On aktiviert wird. ExpressRoute akzeptiert bis zu 200 Präfixe pro BGP-Sitzung für das öffentliche Azure-Peering und das Microsoft-Peering.

Die BGP-Sitzung wird verworfen, wenn die Anzahl von Präfixen den Grenzwert überschreitet. ExpressRoute akzeptiert Standardrouten nur über den Link für privates Peering. Der Anbieter muss die Standardroute und private IP-Adressen (RFC 1918) aus den Pfaden für das öffentliche Azure-Peering und das Microsoft-Peering herausfiltern.

Transitrouting und regionsübergreifendes Routing

ExpressRoute kann nicht als Transitrouter konfiguriert werden. Transitrouting-Dienste erhalten Sie bei Ihrem Konnektivitätsanbieter.

Ankündigen von Standardrouten

Standardrouten sind nur für Sitzungen mit privatem Azure-Peering zulässig. In diesem Fall leitet ExpressRoute den gesamten Datenverkehr aus den zugeordneten virtuellen Netzwerken an Ihr Netzwerk. Das Ankündigen von Standardrouten für das private Peering führt dazu, dass der Internetpfad aus Azure blockiert wird. Sie müssen den Edge-Bereich Ihres Unternehmens nutzen, um Datenverkehr für in Azure gehostete Dienste aus dem Internet und in das Internet zu leiten.

Auf einige Dienste kann nicht von Ihrem Unternehmensedge aus zugegriffen werden. Um die Konnektivität mit anderen Azure-Diensten und Infrastrukturdiensten zu ermöglichen, müssen Sie benutzerdefiniertes Routing verwenden, um die Internetverbindung für jedes Subnetz zu ermöglichen, das eine Internetverbindung für diese Dienste erfordert.

Unterstützung für BGP-Communitys

Dieser Abschnitt enthält eine Übersicht darüber, wie BGP-Communitys mit ExpressRoute verwendet werden. Microsoft kündigt Routen in den Pfaden für das private Peering, das Microsoft-Peering und das öffentliche Peering (veraltet) an, dabei sind die Routen mit den entsprechenden Communitywerten versehen. Die Gründe für diese Vorgehensweise und die Details zu den Communitywerten sind weiter unten beschrieben. Microsoft berücksichtigt aber keine Communitywerte, mit denen Routen gekennzeichnet sind, die gegenüber Microsoft angekündigt werden.

Wenn Sie für privates Peering einen benutzerdefinierten BGP-Communitywert in Ihren virtuellen Azure-Netzwerken konfigurieren, sehen Sie diesen benutzerdefinierten Wert und einen regionalen BGP-Communitywert auf den Azure-Routen, die für Ihre lokale Bereitstellung über ExpressRoute angekündigt werden.

Beim Microsoft-Peering stellen Sie eine Verbindung mit Microsoft über ExpressRoute an einem beliebigen Peeringstandort innerhalb einer geopolitischen Region her. Sie haben auch Zugriff auf alle Microsoft-Clouddienste in allen Regionen innerhalb der geopolitischen Grenze.

Wenn Sie beispielsweise in Amsterdam per ExpressRoute mit Microsoft verbunden sind, haben Sie Zugriff auf alle Microsoft-Clouddienste, die in Europa, Norden, und Europa, Westen, gehostet werden.

Die Seite ExpressRoute-Partner und Peeringstandorte enthält eine ausführliche Liste mit geopolitischen Regionen, dazugehörigen Azure-Regionen und entsprechenden ExpressRoute-Peeringstandorten.

Sie können mehr als eine ExpressRoute-Verbindung pro geopolitischer Region erwerben. Wenn Sie über mehrere Verbindungen verfügen, ergeben sich für Sie aufgrund der Georedundanz daraus erhebliche Vorteile in Bezug auf Hochverfügbarkeit. Bei Verwendung mehrerer ExpressRoute-Leitungen erhalten Sie die gleiche Gruppe von Präfixen, die von Microsoft für Microsoft-Peeringpfade angekündigt werden. Diese Konfiguration ergibt mehrere Pfade von Ihrem Netzwerk zu Microsoft. Diese Einrichtung kann unter Umständen dazu führen, dass in Ihrem Netzwerk suboptimale Routingentscheidungen getroffen werden. Dies kann die Konnektivität für verschiedene Dienste beeinträchtigen. Sie können die Communitywerte nutzen, um die richtigen Routingentscheidungen zu treffen und optimales Routing für Benutzer zu bieten.

Alle Routen, die von Microsoft angekündigt werden, werden mit dem entsprechenden Communitywert gekennzeichnet.

Dienst zu BGP-Communitywert

Zusätzlich zum BGP-Tag für jede Region markiert Microsoft auch Präfixe basierend auf dem Dienst, zu dem sie gehören. dieses Tagging gilt nur für das Microsoft-Peering. Die folgende Tabelle enthält die Zuordnung des Diensts zum BGP-Communitywert. Sie können das Cmdlet „Get-AzBgpServiceCommunity“ ausführen, um eine vollständige Liste der neuesten Werte abzurufen.

(1) Azure Global Services enthält zurzeit nur Azure DevOps.

(2) Autorisierung von Microsoft erforderlich. Weitere Informationen finden Sie unter Konfigurieren von Routenfiltern für das Microsoft-Peering.

(3) In dieser Community werden auch die erforderlichen Routen für Microsoft Teams-Dienste veröffentlicht.

(4) CRM Online unterstützt Dynamics v8.2 und niedriger. Wählen Sie für höhere Versionen die regionale Community für Ihre Dynamics-Bereitstellungen aus.

(5) Die Verwendung von Microsoft Peering mit PSTN-Diensten ist auf bestimmte Anwendungsfälle beschränkt. Weitere Informationen finden Sie unter Verwenden von ExpressRoute für Microsoft-PSTN-Dienste.

BGP-Communityunterstützung in nationalen Clouds

• Office 365-Communitys werden für die Region „Microsoft Azure, betrieben von 21Vianet” nicht über Microsoft Peering unterstützt.

Nächste Schritte

• Konfigurieren Sie Ihre ExpressRoute-Verbindung.

  • Erstellen und Ändern einer Verbindung
  • Erstellen und Ändern einer Peeringkonfiguration
  • Verknüpfen eines VNet mit einer ExpressRoute-Verbindung