Beheben von Problemen mit Azure Route Server
Erfahren Sie, wie Sie einige der gängigen Probleme mit Azure Route Server beheben.
Verbindungsprobleme
Warum verliert mein NVA (Network Virtual Appliance, virtuelles Netzwerkgerät) die Internetkonnektivität, nachdem sie die Standardroute (0.0.0.0/0) für den Routenserver angekündigt hat?
Wenn Ihr NVA die Standardroute ankündigt, programmiert Route Server sie für alle virtuellen Maschinen (Virtual Machines, VMs) im virtuellen Netzwerk, einschließlich der NVA selbst. Diese Standardroute legt die NVA als nächsten Hop für den gesamten Internetdatenverkehr fest. Wenn Ihre NVA Internetkonnektivität benötigt, müssen Sie eine benutzerdefinierte Route (User Defined Route, UDR) konfigurieren, mit der diese Standardroute der NVA außer Kraft gesetzt wird, und die UDR an das Subnetz anfügen, in dem die NVA gehostet wird. Andernfalls sendet der NVA-Hostcomputer weiterhin den Internetdatenverkehr, einschließlich des von der NVA gesendeten Datenverkehrs an die NVA selbst. Weitere Informationen finden Sie unter Benutzerdefinierte Routen.
| Route | Nächster Hop |
|---|---|
| 0.0.0.0/0 | Internet |
Warum verliert das NVA ihre Konnektivität mit dem Route Server, nachdem mithilfe einer benutzerdefinierten Route (User Defined Route, UDR) im GatewaySubnet erzwungen wurde, dass der gesamte Datenverkehr an eine Firewall gesendet wird?
Wenn Sie Ihren lokalen Datenverkehr mithilfe einer Firewall überprüfen möchten, können Sie erzwingen, dass er an sie gesendet wird, indem Sie eine benutzerdefinierte Route (User Defined Route, UDR) im GatewaySubnet verwenden (eine Routingtabelle, die dem GatewaySubnet mit der UDR zugeordnet ist). Diese UDR kann jedoch die Kommunikation zwischen dem Route Server und dem Gateway unterbrechen, indem das Senden dieses Datenverkehr auf der Steuerungsebene (Border Gateway Protocol, BGP) an die Firewall erzwungen wird. (Dieses Problem tritt auf, wenn Sie den Datenverkehr überprüfen, der für das virtuelle Netzwerk mit dem Routenserver bestimmt ist). Um dieses Problem zu vermeiden, müssen Sie der GatewaySubnet-Routingtabelle eine weitere UDR hinzufügen, um den Datenverkehr der Steuerungsebene vom erzwungenen Senden an die Firewall auszunehmen (falls das Hinzufügen einer BGP-Regel für die Firewall nicht gewünscht/möglich ist):
| Route | Nächster Hop |
|---|---|
| 10.0.0.0/16 | 10.0.2.1 |
| 10.0.1.0/27 | VirtualNetwork |
10.0.0.0/16 ist der Adressraum des virtuellen Netzwerks und 10.0.1.0/27 der Adressraum von RouteServerSubnet. 10.0.2.1 ist die IP-Adresse der Firewall.
Ich habe eine benutzerdefinierte Route (UDR) mit dem nächsten Hoptyp als Virtual Network Gateway hinzugefügt, aber diese UDR wird nicht wirksam. Entspricht dies dem erwarteten Verhalten?
Ja, dieses Verhalten wird erwartet. Benutzerdefinierte Routen mit dem nächsten Hoptyp Virtual Network Gateway werden für Subnetze innerhalb des virtuellen Netzwerks und der mit Peering verbundenen virtuellen Netzwerke von Route Server nicht unterstützt. Wenn Sie den nächsten Hop jedoch so konfigurieren möchten, dass es sich um eine virtuelle Netzwerkanwendung (NVA) oder das Internet handelt, wird eine benutzerdefinierte Route mit dem nächsten Hoptyp VirtualAppliance oder Internet unterstützt.
Warum befindet sich in den effektiven Routen der Netzwerkschnittstelle meiner VM eine benutzerdefinierte Route, deren nächster Hop auf den Typ Keiner festgelegt ist?
Wenn Sie eine Route von Ihrer NVA zum Routenserver ankündigen, die eine genaue Präfixübereinstimmung wie eine andere benutzerdefinierte Route hat, muss der nächste Hop der angekündigten Route gültig sein. Wenn der angekündigte nächste Hop ein Lastenausgleich ohne konfigurierten Back-End-Pool ist, hat diese ungültige Route Vorrang vor der benutzerdefinierten Route. In den effektiven Routen der Netzwerkschnittstelle wird die ungültige angekündigte Route als benutzerdefinierte Route angezeigt, wobei der Typ für den nächsten Hop auf Keiner festgelegt ist.
Warum geht die Konnektivität verloren, nachdem dem RouteServerSubnet oder GatewaySubnet eine Dienstendpunktrichtlinie zugeordnet wurde?
Wenn Sie dem RouteServerSubnet oder GatewaySubnet eine Dienstendpunktrichtlinie zuordnen, kann die Kommunikation zwischen der zugrunde liegenden Azure-Verwaltungsplattform und diesen entsprechenden Azure-Diensten (Route Server und VPN/ExpressRoute-Gateway) unterbrochen werden. Dies kann dazu führen, dass diese Azure-Ressourcen in einen fehlerhaften Zustand geraten, wodurch die Konnektivität zwischen Ihren lokalen Workloads und Azure-Workloads verloren geht.
Warum verliere ich die Konnektivität, nachdem ich benutzerdefiniertes DNS anstelle des Standards (von Azure bereitgestelltes DNS) für das virtuelle Netzwerk von Route Server verwendet habe?
Stellen Sie für das virtuelle Netzwerk, in dem Route Server bereitgestellt wird, sicher, dass ihre benutzerdefinierte DNS-Konfiguration öffentliche Domänennamen auflösen kann, wenn Sie keine (von Azure zur Verfügung gestellte) Standard-DNS verwenden. Dadurch wird sichergestellt, dass Azure-Dienste (Route Server und VPN/ExpressRoute-Gateway) mit der zugrunde liegenden Verwaltungsebene von Azure kommunizieren können. Weitere Informationen zu Wildcardregeln finden Sie in der Dokumentation zu Azure DNS Private Resolver.
Warum kann ich die BGP-Peer-IP des Routenservers von meinem NVA aus nicht über TCP anpingen, nachdem ich das BGP-Peering zwischen ihnen eingerichtet habe?
In manchen NVAs müssen Sie eine statische Route zum Route Server-Subnetz hinzufügen, um den Routenserver von der NVA über TCP anpingen zu können und eine BGP-Peering-Fluktuation zu vermeiden. Wenn sich beispielsweise der Routenserver in 10.0.255.0/27 und Ihr NVA in 10.0.1.0/24 befindet, müssen Sie der Routingtabelle auf dem NVA die folgende Route hinzufügen:
| Route | Nächster Hop |
|---|---|
| 10.0.255.0/27 | 10.0.1.1 |
10.0.1.1 ist die Standardgateway-IP-Adresse in dem Subnetz, in dem Ihr NVA (oder genauer gesagt eine der NICs) gehostet wird.
Warum geht bei der Bereitstellung eines Routenservers in einem virtuellen Netzwerk, das bereits über ein ExpressRoute-Gateway und/oder ein Azure-VPN-Gateway verfügt, die Konnektivität mit meinem lokalen Netzwerk über ExpressRoute und/oder Azure-VPN verloren?
Wenn Sie einen Routenserver in einem virtuellen Netzwerk bereitstellen, muss die Steuerungsebene zwischen den Gateways und dem virtuellen Netzwerk aktualisiert werden. Während dieser Aktualisierung wird die Konnektivität der VMs im virtuellen Netzwerk mit dem lokalen Netzwerk für einen gewissen Zeitraum getrennt. Es wird daher dringend empfohlen, eine Wartung für die Bereitstellung eines Routenservers in Ihrer Produktionsumgebung zu planen.
Probleme mit der Steuerungsebene
Warum erhält mein lokales Netzwerk, das mit dem Azure-VPN-Gateway verbunden ist, nicht die vom Routenserver angekündigte Standardroute?
Azure VPN Gateway kann zwar die Standardroute von seinen BGP-Peers einschließlich des Routenservers empfangen, aber die Standardroute wird anderen Peers nicht angekündigt.
Warum empfängt mein NVA keine Routen vom Routenserver, obwohl das BGP-Peering aktiv ist?
Die vom Routenserver verwendete ASN lautet 65515. Konfigurieren Sie unbedingt eine andere ASN für Ihr NVA, damit eine eBGP-Sitzung zwischen Ihrem NVA und dem Routenserver eingerichtet werden und die Routenverteilung automatisch erfolgen kann. In Ihrer BGP-Konfiguration muss unbedingt „Multihop“ aktiviert werden, da sich Ihr NVA und der Routenserver in unterschiedlichen Subnetzen des virtuellen Netzwerks befinden.
Das BGP-Peering zwischen meinem NVA und dem Routenserver ist aktiv. Ich kann sehen, dass die Routen zwischen ihnen richtig ausgetauscht werden. Warum sind die NVA-Routen nicht in der gültigen Routingtabelle meines virtuellen Computers enthalten?
Wenn sich Ihr virtueller Computer im selben virtuellen Netzwerk befindet wie Ihr NVA und Ihr Routenserver:
Route Server macht zwei BGP-Peer-IPs verfügbar, die auf zwei VMs gehostet werden, die für das Senden der Routen an alle anderen VMs in Ihrem virtuellen Netzwerk zuständig sind. Jede NVA muss für die beiden VMs zwei identische BGP-Sitzungen einrichten (z. B. dieselbe ASN und denselben AS-Pfad verwenden und dieselben Routen ankündigen), damit Ihre VMs im virtuellen Netzwerk konsistente Routinginformationen von Azure Route Server erhalten können.
Wenn Sie über zwei oder mehr Instanzen des NVAs verfügen, können Sie verschiedene AS-Pfade für dieselbe Route von verschiedenen NVA-Instanzen ankündigen, wenn Sie eine NVA-Instanz als aktiv und die andere als passiv festlegen möchten.
Wenn sich Ihr virtueller Computer in einem anderen virtuellen Netzwerk befindet als dem, in dem Ihr NVA und der Routenserver gehostet werden: Überprüfen Sie, ob das VNet-Peering zwischen den beiden VNets und „Remote-Route Server verwenden“ für das VNet Ihrer VM aktiviert ist.
Warum ist Equal-Cost Multi-Path-Funktion (ECMP) meiner ExpressRoute-Verbindung deaktiviert, nachdem ich den Routenserver im virtuellen Netzwerk bereitgestellt habe?
Wenn Sie dieselben Routen aus Ihrem lokalen Netzwerk über mehrere ExpressRoute-Verbindungen an Azure ankündigen, ist ECMP normalerweise standardmäßig für den Datenverkehr aktiviert, der für diese Routen von Azure zurück zu Ihrem lokalen Netzwerk bestimmt ist. Nach der Bereitstellung des Routenservers gehen die Informationen mit mehreren Pfaden derzeit beim BGP-Austausch zwischen ExpressRoute und dem Routenserver verloren, und der Datenverkehr von Azure durchläuft daher nur eine der ExpressRoute-Verbindungen.
Nächster Schritt
Weitere Informationen zum Erstellen und Konfigurieren von Azure Route Server finden Sie hier: