Optimieren von ExpressRoute-Routing
Wenn Sie mehrere ExpressRoute-Verbindungen nutzen, verfügen Sie über mehr als einen Weg zur Herstellung einer Verbindung mit Microsoft. Dies kann ein suboptimales Routing zur Folge haben. Es kann also sein, dass Ihr Datenverkehr für den Weg zu Microsoft und von Microsoft in Ihr Netzwerk mehr Zeit benötigt. Je länger der Netzwerkpfad, desto höher die Latenz. Die Latenz wirkt sich direkt auf die Anwendungsleistung und die Benutzerfreundlichkeit aus. In diesem Artikel wird dieses Problem veranschaulicht, und es wird beschrieben, wie Sie das Routing mit den standardmäßigen Routingtechnologien optimieren.
Pfadauswahl für Microsoft-Peering
Sie müssen unbedingt sicherstellen, dass der Datenverkehr bei der Verwendung von Microsoft-Peering über den gewünschten Pfad fließt, wenn Sie eine oder mehrere ExpressRoute-Verbindungen haben. Sie müssen ferner sicherstellen, dass Pfade zum Internet einen Internet Exchange (IX) oder Internetdienstanbieter (ISP) verwenden. BGP nutzt einen Algorithmus zur Auswahl des optimalen Pfads auf der Grundlage vieler Faktoren, einschließlich der längsten Präfixübereinstimmung (Longest Prefix Match, LPM). Um sicherzustellen, dass der für Azure bestimmte, über Microsoft-Peering laufende Datenverkehr den ExpressRoute-Pfad durchläuft, müssen Sie das Attribut Lokale Einstellung implementieren. Diese Einstellung stellt sicher, dass der Pfad in ExpressRoute immer bevorzugt wird.
Hinweis
Der Standardwert für die lokale Präferenz beträgt in der Regel 100. Höhere lokale Einstellungen werden bevorzugt.
Betrachten Sie das folgende Beispielszenario:
Im obigen Beispiel konfigurieren Sie „Lokale Einstellung“ wie folgt, um ExpressRoute-Pfade zu bevorzugen.
Cisco IOS-XE-Konfiguration aus R1-Sicht:
R1(config)#route-map prefer-ExR permit 10
R1(config-route-map)#set local-preference 150
R1(config)#router BGP 345
R1(config-router)#neighbor 1.1.1.2 remote-as 12076
R1(config-router)#neighbor 1.1.1.2 activate
R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in
Junos-Konfiguration aus R1-Sicht:
- user@R1# set protocols bgp group ibgp type internal
- user@R1# set protocols bgp group ibgp local-preference 150
Suboptimales Routing (Kunde an Microsoft)
Wir sehen uns nun ein Beispiel zum Routingproblem an. Angenommen, Sie verfügen über zwei Niederlassungen in den USA: eine in Los Angeles und eine in New York. Die Niederlassungen sind über ein Wide Area Network (WAN) verbunden, wobei es sich entweder um Ihr eigenes Backbonenetzwerk oder die IP-VPN-Verbindung Ihres Service Providers handeln kann. Sie verfügen über zwei ExpressRoute-Verbindungen, eine in „USA, Westen“ und eine in „USA, Osten“. Beide sind außerdem über das WAN verbunden. Es sind also zwei Wege zum Herstellen der Verbindung mit dem Microsoft-Netzwerk vorhanden.
Nehmen Sie weiter an, dass Sie über jeweils eine Azure-Bereitstellung, z. B. über einen Azure App Service, in „USA, Westen“ und „USA, Osten“ verfügen. Sie haben die Absicht, Ihre Benutzer in Los Angeles mit der Azure-Region „USA, Westen“ und Benutzer in New York mit der Azure-Region „USA, Osten“ zu verbinden. Der Grund für diese Einrichtung ist, dass Ihr Dienstadministrator angibt, dass Benutzer in jedem Büro auf die Azure-Dienste in der Nähe zugreifen, um optimale Erfahrungen zu erhalten. Der Plan funktioniert für die Benutzer an der Ostküste gut, aber nicht für die Benutzer an der Westküste.
Die Ursache des Problems besteht darin, dass wir für jede ExpressRoute-Verbindung lokal sowohl das Präfix in der Azure-Region „USA, Osten“ (23.100.0.0/16) als auch das Präfix in der Azure-Region „USA, Westen“ (13.100.0.0/16) angeben. Wenn Sie nicht wissen, welches Präfix für welche Region gilt, können Sie die Präfixe auch nicht unterschiedlich behandeln. Für Ihr WAN kann der Eindruck entstehen, dass beide Präfixe näher an „USA, Osten“ als an „USA, Westen“ liegen, sodass die Benutzer beider Niederlassungen an die ExpressRoute-Verbindung in der Region „USA, Osten“ geleitet werden. Das Ergebnis ist, dass es in der Niederlassung in Los Angeles viele unzufriedene Benutzer gibt.
Lösung: Verwenden von BGP-Communitys
Zum Optimieren des Routings für die Benutzer beider Niederlassungen müssen Sie wissen, welches Präfix für die Azure-Region „USA, Westen“ und welches Präfix für die Region „USA, Osten“ gilt. Wir codieren diese Informationen mithilfe von BGP-Communitywerten. Wir haben jeder Azure-Region einen eindeutigen BGP-Communitywert zugewiesen, z. B. 12076:51004 für „USA, Osten“ und 12076:51006 für „USA, Westen“. Da Sie jetzt wissen, welches Präfix für welche Azure-Region gilt, können Sie konfigurieren, welche ExpressRoute-Verbindung vorgezogen werden sollte. Da wir BGP zum Austauschen von Routinginformationen verwenden, können Sie die lokale Einstellung von BGP nutzen, um das Routing zu beeinflussen.
In unserem Beispiel können Sie 13.100.0.0/16 in „USA, Westen“ einen höheren Wert für die lokale Einstellung als für „USA, Osten“ zuweisen (bzw. einen höheren Wert für die lokale Einstellung für 23.100.0.0/16 in „USA, Osten“ als in „USA, Westen“). Mit dieser Konfiguration wird Folgendes sichergestellt: Wenn beide Wege zu Microsoft verfügbar sind, verwenden die Benutzer in Los Angeles die ExpressRoute-Verbindung in „USA, Westen“ zum Herstellen der Verbindung mit Azure „USA, Westen“, während die Benutzer in New York die ExpressRoute-Verbindung in „USA, Osten“ zum Herstellen der Verbindung mit Azure „USA, Osten“ verwenden. Das Routing ist somit auf beiden Seiten optimiert.
Hinweis
Bei Nutzung des privaten Peerings kann das gleiche Verfahren unter Verwendung der lokalen Einstellung (Local Preference) auch auf die Weiterleitung vom Kunden zum Azure Virtual Network angewendet werden. Microsoft verknüpfen den BGP-Community-Wert nicht mit den Präfixen, die von Azure für Ihr Netzwerk angekündigt werden. Da Sie aber wissen, welche Ihrer Bereitstellungen des virtuellen Netzwerks sich jeweils in der Nähe der einzelnen Büros befindet, können Sie Ihre Router entsprechend konfigurieren, damit Sie eine ExpressRoute-Leitung einer anderen Leitung vorziehen können.
Suboptimales Routing (Microsoft an Kunde)
In diesem Beispiel legen Verbindungen von Microsoft einen längeren Weg zum Erreichen Ihres Netzwerks zurück. In diesem Fall verwenden Sie lokale Exchange-Server und Exchange Online in einer Hybridumgebung. Ihre Niederlassungen sind mit einem WAN verbunden. Sie kündigen die Präfixe Ihrer lokalen Server in beiden Niederlassungen gegenüber Microsoft über zwei ExpressRoute-Verbindungen an.
Exchange Online initiiert Verbindungen mit den lokalen Servern in Fällen wie der Postfachmigration. Die Verbindung mit der Niederlassung in Los Angeles wird an die ExpressRoute-Verbindung in „USA, Osten“ geleitet, bevor der Weg über den ganzen Kontinent zurück an die Westküste zurückgelegt wird. Die Ursache des Problems ist ähnlich wie im ersten Fall. Ohne entsprechenden Hinweis kann das Microsoft-Netzwerk nicht ermitteln, welches lokale Präfix näher an „USA, Osten“ und welches näher an „USA, Westen“ liegt. So wird der falsche Weg zu Ihrer Niederlassung in Los Angeles gewählt.
Lösung: Voranstellen von AS PATH
Es gibt zwei Lösungen des Problems. Die erste besteht darin, einfach das lokale Präfix 177.2.0.0/31 für Ihre Niederlassung in Los Angeles für die ExpressRoute-Verbindung in „USA, Westen“ anzugeben. Anschließend kündigen Sie Ihr lokales Präfix für Ihre Niederlassung in New York, 177.2.0.2/31, für die ExpressRoute-Verbindung in „USA, Osten“ an. Im Ergebnis ist für Microsoft nur noch ein Weg zum Herstellen der Verbindung mit Ihren Niederlassungen vorhanden. Die Mehrdeutigkeit wurde beseitigt, und das Routing wurde optimiert. Bei diesem Aufbau müssen Sie sich Gedanken über Ihre Failoverstrategie machen. Falls der Pfad zu Microsoft per ExpressRoute unterbrochen wird, müssen Sie sicherstellen, dass Exchange Online weiterhin eine Verbindung mit Ihren lokalen Servern herstellen kann.
Die zweite Lösung besteht darin, weiterhin beide Präfixe unter beiden ExpressRoute-Verbindungen anzukündigen und darauf hinzuweisen, welches Präfix in der Nähe welcher Niederlassung liegt. Da die BGP-Voranstellung von AS Path unterstützt wird, können Sie AS Path für Ihr Präfix konfigurieren, um das Routing zu beeinflussen. In diesem Beispiel können Sie die AS PATH-Anweisung für 172.2.0.0/31 in „USA, Osten“ verlängern, damit die ExpressRoute-Verbindung in „USA, Westen“ für Datenverkehr vorgezogen wird, der für dieses Präfix bestimmt ist. Analog dazu können Sie AS PATH für 172.2.0.2/31 in „USA, Westen“ verlängern, damit von uns die ExpressRoute-Verbindung in „USA, Osten“ vorgezogen wird. Das Routing ist dann für beide Büros optimiert. Wenn bei diesem Aufbau eine ExpressRoute-Verbindung unterbrochen wird, kann Exchange Online Sie trotzdem noch über eine andere ExpressRoute-Verbindung und Ihr WAN erreichen.
Wichtig
Wir entfernen private AS-Nummern in AS PATH für die unter Microsoft-Peering empfangenen Präfixe (bei Verwendung des Peerings mit einer privaten AS-Nummer). Sie müssen ein Peering mit einem öffentlichen AS verwenden und in AS PATH öffentliche AS-Nummern anfügen, um das Routing für Microsoft-Peering zu beeinflussen.
Hinweis
Die hier aufgeführten Beispiele gelten zwar für Microsoft-Peering, für privates Peering werden jedoch die gleichen Funktionen unterstützt. Das Voranstellen von AS PATH funktioniert darüber hinaus in einer einzelnen ExpressRoute-Verbindung, sodass die Auswahl der primären und sekundären Pfade beeinflusst werden kann.
Suboptimales Routing zwischen virtuellen Netzwerken
Mit ExpressRoute können Sie die Kommunikation von virtuellem Netzwerk zu virtuellem Netzwerk („VNet“) ermöglichen, indem Sie diese mit einer ExpressRoute-Verbindung verknüpfen. Bei einer Verknüpfung mit mehreren ExpressRoute-Verbindungen kann das suboptimale Routing zwischen den VNets erfolgen. Wir sehen uns hierzu ein Beispiel an. Sie verfügen über zwei ExpressRoute-Verbindungen, eine in „USA, Westen“ und eine in „USA, Osten“. In jeder Region sind zwei VNets vorhanden. Ihre Webserver werden in dem einem VNet und die Anwendungsserver im anderen VNet bereitgestellt. Aus Redundanzgründen verknüpfen Sie die beiden VNets in jeder Region sowohl mit der lokalen ExpressRoute-Verbindung als auch mit der ExpressRoute-Verbindung am Remotestandort. Wie im folgenden Diagramm zu sehen ist, führen von jedem VNet zwei Pfade zum anderen VNet. Die VNets haben keine Informationen dazu, welche ExpressRoute-Verbindung lokal und welche remote ist. Da ECMP-Routing (Equal-Cost-Multi-Path) verwendet wird, um den Lastenausgleich für Datenverkehr zwischen VNets zu ermöglichen, werden für einige Datenverkehrsflüsse der längere Pfad und die Weiterleitung über die ExpressRoute-Remoteverbindung gewählt.
Lösung: Zuweisen einer Verbindung vom Typ „Hohe Gewichtung zu lokal“
Die Lösung ist einfach. Da Sie wissen, wo sich die VNets und die Verbindungen befinden, können Sie uns mitteilen, welcher Pfad für die einzelnen VNets jeweils bevorzugt genutzt werden soll. Speziell für dieses Beispiel gilt, dass Sie der lokalen Verbindung eine höhere Gewichtung als der Remoteverbindung verleihen (siehe Konfigurationsbeispiel hier). Wenn ein VNet das Präfix des anderen VNet über mehrere Verbindungen empfängt, wird die Verbindung mit der höchsten Gewichtung bevorzugt zum Senden von Datenverkehr verwendet, der für dieses Präfix bestimmt ist.
Hinweis
Außerdem können Sie die Weiterleitung aus dem VNet an Ihr lokales Netzwerk beeinflussen, wenn Sie über mehrere ExpressRoute-Verbindungen verfügen, indem Sie die Gewichtung einer Verbindung konfigurieren, anstatt das Voranstellen von AS PATH anzuwenden. Diese Vorgehensweise wird im zweiten Szenario beschrieben. Für jedes Präfix sehen wir uns vor der AS PATH-Länge immer die Gewichtung der Verbindung an, wenn die Entscheidung darüber getroffen werden soll, wie der Datenverkehr gesendet wird.
Nächste Schritte
- Erfahren Sie mehr über das Entwerfen von ExpressRoute für Hochverfügbarkeit.
- Erfahren Sie mehr über das Entwerfen von ExpressRoute für die Notfallwiederherstellung.