Beheben von Problemen mit Azure Route Server

Erfahren Sie, wie Sie einige der gängigen Probleme mit Azure Route Server beheben.

Verbindungsprobleme

Warum verliert meine virtuelle Anwendung (NVA) die Internetverbindung, nachdem sie die Standardroute (0.0.0.0/0/0) an den Route Server angekündigt hat?

Wenn Ihre NVA die Standardroute ankündigen, programmiert der Route-Server sie für alle virtuellen Computer (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 der NVA seine Konnektivität mit dem Route Server, nachdem der gesamte Datenverkehr zu einer Firewall mit einer benutzerdefinierten Route (UDR) im GatewaySubnet erzwungen wurde?

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.

Warum kann ich tcp-ping von meinem NVA nicht an die BGP-Peer-IP des Route-Servers, nachdem ich das BGP-Peering zwischen ihnen eingerichtet habe?

In einigen NVAs müssen Sie eine statische Route zum Routingserver-Subnetz hinzufügen, um TCP-Ping des Routingservers vom NVA zu senden und BGP-Peering-Flapping zu vermeiden. Wenn sich der Route Server beispielsweise in 10.0.255.0/27 befindet und sich der NVA in 10.0.1.0/24 befindet, müssen Sie die folgende Route zur Routingtabelle in der NVA 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 verliere ich die Verbindung zu meinem lokalen Netzwerk über ExpressRoute und/oder Azure VPN, wenn ich einen Route Server in einem virtuellen Netzwerk bereitstellen möchte, das bereits über expressRoute-Gateway und/oder Azure VPN-Gateway verfügt?

Wenn Sie einen Route Server in einem virtuellen Netzwerk bereitstellen, müssen wir die Steuerebene zwischen den Gateways und dem virtuellen Netzwerk aktualisieren. 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 dringend empfohlen, Standard Zusätzlichkeit für die Bereitstellung eines Route-Servers in Ihrer Produktionsumgebung zu planen.

Probleme mit der Steuerungsebene

Warum empfängt mein lokales Netzwerk, das mit dem Azure VPN-Gateway verbunden ist, nicht die vom Route Server angekündigte Standardroute?

Obwohl das Azure VPN-Gateway die Standardroute von den BGP-Peers einschließlich des Route-Servers empfangen kann, wird die Standardroute für andere Peers nicht angekündigt.

Warum empfängt meine NVA keine Routen vom Route Server, obwohl das BGP-Peering aktiviert ist?

Der ASN, den der Route-Server verwendet, beträgt 65515. Stellen Sie sicher, dass Sie einen anderen ASN für Ihre NVA konfigurieren, damit eine eBGP-Sitzung zwischen Dem NVA und Route Server hergestellt werden kann, damit die Routenverteilung automatisch erfolgen kann. Stellen Sie sicher, dass Sie "Multi-Hop" in Ihrer BGP-Konfiguration aktivieren, da sich Ihre NVA und der Route-Server in verschiedenen Subnetzen im virtuellen Netzwerk befinden.

Das BGP-Peering zwischen meinem NVA und route Server ist hoch. 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 Ihre VM im selben virtuellen Netzwerk wie Ihr NVA- und Routingserver befindet:

    Route Server macht zwei BGP-Peer-IPs verfügbar, die auf zwei virtuellen Computern gehostet werden, die die Verantwortung für das Senden der Routen an alle anderen virtuellen Computer teilen, die in Ihrem virtuellen Netzwerk ausgeführt werden. 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.

    Diagram showing a network virtual appliance (NVA) with Azure Route Server.

    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 Ihre VM in einem anderen virtuellen Netzwerk befindet als das, das Ihre NVA und den Route-Server hosten. Ü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 die Funktion "Multi-Path (Equal-Cost Multi-Path, ECMP)" meiner ExpressRoute deaktiviert, nachdem ich Route Server 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. Wenn Sie den Route-Server bereitstellen, gehen beim Bereitstellen des Route-Servers informationen im BGP-Austausch zwischen ExpressRoute und dem Route Server verloren, und daher durchläuft der Datenverkehr von Azure nur auf einer der ExpressRoute-Verbindungen.

Nächster Schritt

Weitere Informationen zum Erstellen und Konfigurieren von Azure Route Server finden Sie hier: