ExpressRoute-Routinganforderungen

Um mithilfe von ExpressRoute eine Verbindung mit Microsoft-Clouddiensten herzustellen, müssen Sie 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. Falls sie dies nicht tun, müssen Sie die folgenden Anforderungen einhalten.

Eine Beschreibung der Routingsitzungen, die Sie einrichten müssen, um die Konnektivität zu erleichtern, finden Sie unter "Schaltkreise und Routingdomänen".

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 der Anforderungen und beschreibt die Regeln, wie Sie diese IP-Adressen erwerben und verwenden müssen.

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, den Sie zum Konfigurieren von Routen verwenden, kann nicht mit Adressbereichen überlappen, die für virtuelle Netzwerke in Azure verwendet werden.

• IPv4:
  • Reservieren Sie ein /29 Subnetz oder zwei /30 Subnetze für Routingschnittstellen.
  • Verwenden Sie entweder private IP-Adressen oder öffentliche IP-Adressen für die Subnetze, die für das Routing verwendet werden.
  • 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 Sie ein /29 Subnetz verwenden, teilen Sie es in zwei /30 Subnetze auf.
    • Verwenden Sie das erste /30 Subnetz für die primäre Verbindung und das zweite /30 Subnetz für die sekundäre Verbindung.
    • Verwenden Sie für jedes Subnetz /30 die erste IP-Adresse des /30 Subnetzes für Ihren Router. Microsoft verwendet die zweite IP-Adresse des /30-Subnetzes zum Einrichten einer BGP-Sitzung.
    • Sie müssen beide BGP-Sitzungen einrichten, damit das Verfügbarkeits-SLA gültig ist.
• IPv6:
  • Reservieren Sie ein /125 Subnetz oder zwei /126 Subnetze für Routingschnittstellen.
  • Verwenden Sie entweder private IP-Adressen oder öffentliche IP-Adressen für die Subnetze, die für das Routing verwendet werden.
  • 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 Sie ein /125 Subnetz verwenden, teilen Sie es in zwei /126 Subnetze auf.
    • Verwenden Sie das erste /126 Subnetz für die primäre Verbindung und das zweite /126 Subnetz für die sekundäre Verbindung.
    • Verwenden Sie für jedes Subnetz /126 die erste IP-Adresse des /126 Subnetzes für Ihren Router. Microsoft verwendet die zweite IP-Adresse des /126-Subnetzes zum Einrichten einer BGP-Sitzung.
    • Sie müssen beide BGP-Sitzungen einrichten, damit das Verfügbarkeits-SLA gültig ist.

Beispiel für privates Peering

Wenn Sie sich dafür entscheiden, a.b.c.d/29 zum Einrichten des Peerings zu verwenden, teilen Sie es in zwei /30 Subnetze auf. Beachten Sie im folgenden Beispiel, wie das Subnetz a.b.c.d/29 verwendet wird:

• Aufteilen a.b.c.d/29 in a.b.c.d/30 und a.b.c.d+4/30. Übergeben Sie diese Subnetze über die Bereitstellungs-APIs an Microsoft.
  • Verwenden Sie a.b.c.d+1 als VRF-IP für das primäre PE, und Microsoft verwendet a.b.c.d+2 als VRF-IP für den primären MSEE.
  • Verwenden Sie a.b.c.d+5 als VRF IP für den sekundären PE und Microsoft verwendet a.b.c.d+6 als VRF IP für die sekundäre 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

Um die BGP-Sitzungen einzurichten, verwenden Sie öffentliche IP-Adressen, die Sie besitzen. 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.

• Das Portal listet IPs für angekündigte öffentliche Präfixe für Microsoft Peering auf. Diese IPs erstellen ACLs für die Microsoft-Kernrouter, um eingehenden Datenverkehr von diesen IPs zuzulassen.
• Verwenden Sie ein eindeutiges /29 (IPv4) oder /125 (IPv6)-Subnetz oder zwei /30 (IPv4) oder /126 (IPv6)-Subnetze, um das BGP-Peering für jeden Peering pro ExpressRoute-Schaltkreis einzurichten, wenn Sie mehrere haben.
• Wenn Sie ein /29 Subnetz verwenden, teilen Sie es in zwei /30 Subnetze auf.
• Verwenden Sie das erste /30 Subnetz für die primäre Verbindung und das zweite /30 Subnetz für die sekundäre Verbindung.
• Verwenden Sie für jedes Subnetz /30 die erste IP-Adresse des /30 Subnetzes auf Ihrem Router. Microsoft verwendet die zweite IP-Adresse des /30-Subnetzes zum Einrichten einer BGP-Sitzung.
• Wenn Sie ein /125 Subnetz verwenden, teilen Sie es in zwei /126 Subnetze auf.
• Verwenden Sie das erste /126 Subnetz für die primäre Verbindung und das zweite /126 Subnetz für die sekundäre Verbindung.
• Verwenden Sie für jedes Subnetz /126 die erste IP-Adresse des /126 Subnetzes auf Ihrem Router. Microsoft verwendet die zweite IP-Adresse des /126-Subnetzes zum Einrichten einer BGP-Sitzung.
• Sie müssen beide BGP-Sitzungen einrichten, damit das Verfügbarkeits-SLA gültig ist.

Anforderung einer öffentlichen IP-Adresse

Privates Peering

Bei privatem Peering können Sie öffentliche oder private IPv4-Adressen verwenden. Azure bietet eine End-to-End-Isolation Ihres Datenverkehrs, sodass überlappende Adressen mit anderen Kunden für private Peerings nicht möglich sind. Diese Adressen werden nicht für das Internet angekündigt.

Microsoft-Peering

Mithilfe des Microsoft-Peeringpfads können Sie eine Verbindung mit Microsoft-Clouddiensten herstellen. Diese Liste der Dienste umfasst Microsoft 365-Dienste wie Exchange Online, SharePoint Online und Microsoft Teams. Microsoft unterstützt die bidirektionale Konnektivität für das Microsoft-Peering. Datenverkehr, der für Microsoft-Clouddienste bestimmt ist, muss gültige öffentliche IPv4-Adressen verwenden, bevor er das Microsoft-Netzwerk eingibt.

Stellen Sie sicher, dass Sie als Besitzer Ihrer IP-Adresse und der AS-Nummer 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.

Sie können eine private AS-Nummer mit Microsoft-Peering verwenden, erfordert jedoch eine manuelle Überprüfung. Darüber hinaus entfernt Microsoft private AS-Nummern im AS PATH für die empfangenen Präfixe. Daher können Sie keine privaten AS-Nummern im AS PATH anfügen, um das Routing für Microsoft-Peering zu beeinflussen. Außerdem sind AS-Nummern 64496 bis 64511, die von IANA für Dokumentationszwecke reserviert sind, im Pfad nicht zulässig.

Dynamischer Routenaustausch

Routingaustausch erfolgt über das eBGP-Protokoll. Die MSEEs und Ihre Router richten eBGP-Sitzungen ein. Die Authentifizierung von BGP-Sitzungen ist nicht erforderlich. Bei Bedarf können Sie einen MD5-Hash konfigurieren. Weitere Informationen zum Konfigurieren von BGP-Sitzungen finden Sie unter Konfigurieren von Routing - und Schaltkreisbereitstellungsworkflows und Schaltkreiszuständen.

Autonome Systemnummern (ASN)

Microsoft verwendet AS 12076 für Azure Public, Azure Private und Microsoft Peering. Microsoft reserviert ASNs von 65.515 bis 65.520 für die interne Verwendung. ExpressRoute unterstützt sowohl 16-Bit- als auch 32-Bit-AS-Nummern.

Es gibt keine Anforderungen in Bezug auf die Symmetrie der Datenübertragung. Die Vorwärts- und Rückgabepfade können verschiedene Routerpaare durchlaufen. Sie müssen identische Routen von beiden Seiten über mehrere Ihnen gehörende Circuit-Paare ankündigen. Routenmetriken müssen nicht identisch sein.

Routenaggregation- und Präfixgrenzen

ExpressRoute unterstützt bis zu 4.000 IPv4-Präfixe und 100 IPv6-Präfixe, die über das private Azure-Peering an Microsoft angekündigt wurden. Sie können diesen Grenzwert auf 10.000 IPv4-Präfixe erhöhen, indem Sie das ExpressRoute Premium-Add-On aktivieren. ExpressRoute akzeptiert bis zu 200 Präfixe pro BGP-Sitzung für Azure Public und Microsoft-Peering.

Die BGP-Sitzung fällt aus, wenn die Anzahl der Präfixe das Limit überschreitet. ExpressRoute akzeptiert standardrouten nur für den privaten Peeringlink. Sie müssen Standardrouten und private IP-Adressen (RFC 1918) aus den öffentlichen Azure- und Microsoft-Peeringpfaden herausfiltern.

Transitrouting und regionsübergreifendes Routing

Sie können ExpressRoute nicht als Transitrouter konfigurieren. Sie müssen sich auf Ihren Konnektivitätsanbieter für Transitroutingdienste verlassen.

Ankündigen von Standardrouten

Sie können Standardrouten nur in privaten Azure-Peeringsitzungen ankündigen. In dieser Konfiguration leitet ExpressRoute den gesamten Datenverkehr von den zugeordneten virtuellen Netzwerken an Ihr Netzwerk weiter. Wenn Sie Standardrouten für privates Peering ankündigen, blockieren Sie den Internetpfad von Azure. 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.

Sie können nicht auf einige Dienste von Ihrem Unternehmensrand aus zugreifen. 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-Communities

Dieser Abschnitt enthält eine Übersicht darüber, wie BGP-Communitys mit ExpressRoute arbeiten. Microsoft kündigt Routen in den privaten, Microsoft- und öffentlichen (veraltet) Peering-Pfaden mit Routen an, die mit entsprechenden Community-Werten getaggt sind. Die Gründe dafür und die Details zu Communitywerten werden in den folgenden Abschnitten beschrieben. Microsoft erkennt jedoch keine Community-Werte an, die an Routen, die an Microsoft angekündigt wurden, getaggt sind.

Wenn Sie für private Peering einen benutzerdefinierten BGP-Communitywert in Ihren virtuellen Azure-Netzwerken konfigurieren, wird dieser benutzerdefinierte Wert und ein regionaler BGP-Communitywert auf den Azure-Routen angezeigt, die Sie für Ihre lokale Bereitstellung über ExpressRoute bewerben.

Für 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 über ExpressRoute eine Verbindung mit Microsoft in Amsterdam herstellen, haben Sie Zugriff auf alle Microsoft-Clouddienste, die in Nord- und Westeuropa 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-Verbindungen 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 Konfiguration kann potenziell zu suboptimalen Routingentscheidungen innerhalb Ihres Netzwerks führen. Daher können Sie suboptimale Verbindungserfahrungen mit verschiedenen Diensten erleben. Sie können die Communitywerte nutzen, um die richtigen Routingentscheidungen zu treffen und optimales Routing für Benutzer zu bieten.

Alle von Microsoft angekündigten Routen enthalten das entsprechende Community-Wertetikett.

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 Microsoft-Peering. Die folgende Tabelle enthält die Zuordnung des Diensts zum BGP-Communitywert. Sie können das Get-AzBgpServiceCommunity Cmdlet für eine vollständige Liste der neuesten Werte ausführen.

(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 früher. 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 eines Schaltkreises
  • Erstellen und Ändern der Peeringkonfiguration.
  • Verknüpfen sie ein VNet mit einem ExpressRoute-Schaltkreis.