Felsöka problem med Azure Route Server
Lär dig hur du felsöker några av de vanliga problemen med Azure Route Server.
Anslutningsproblem
Varför förlorar min virtuella nätverksinstallation (NVA) internetanslutningen när den annonserar standardvägen (0.0.0.0/0) till routningsservern?
När din NVA annonserar standardvägen programmerar routningsservern den för alla virtuella datorer (VM) i det virtuella nätverket, inklusive själva NVA:n. Den här standardvägen anger NVA som nästa hopp för all internetbunden trafik. Om din NVA behöver internetanslutning måste du konfigurera en användardefinierad väg (UDR) för att åsidosätta den här standardvägen från NVA och koppla UDR till det undernät där NVA finns. Annars fortsätter NVA-värddatorn att skicka internetbunden trafik, inklusive den som skickas av NVA tillbaka till själva NVA:n. Mer information finns i användardefinierade vägar.
| Flöde | Nästa hopp |
|---|---|
| 0.0.0.0/0 | Internet |
Varför förlorar NVA sin anslutning till routningsservern när all trafik till en brandvägg har tvingats fram med hjälp av en användardefinierad väg (UDR) på GatewaySubnet?
Om du vill inspektera din lokala trafik med hjälp av en brandvägg kan du tvinga all lokal trafik till brandväggen med hjälp av en användardefinierad väg (UDR) i GatewaySubnet (en routningstabell som är associerad med GatewaySubnet som har UDR). Denna UDR kan dock bryta kommunikationen mellan routningsservern och gatewayen genom att tvinga deras kontrollplanstrafik (BGP) till brandväggen (det här problemet uppstår om du inspekterar trafiken som är avsedd för det virtuella nätverket som har routningsservern). För att undvika det här problemet måste du lägga till ytterligare en UDR i routningstabellen GatewaySubnet för att undanta kontrollplanstrafik från att tvingas till brandväggen (om det inte är önskvärt/möjligt att lägga till en BGP-regel i brandväggen):
| Flöde | Nästa hopp |
|---|---|
| 10.0.0.0/16 | 10.0.2.1 |
| 10.0.1.0/27 | VirtualNetwork |
10.0.0.0/16 är adressutrymmet för det virtuella nätverket och 10.0.1.0/27 är adressutrymmet för RouteServerSubnet. 10.0.2.1 är brandväggens IP-adress.
Jag har lagt till en användardefinierad väg (UDR) med nästa hopptyp som Virtuell nätverksgateway, men den här UDR börjar inte gälla. Är detta förväntat?
Ja, det här är förväntat beteende. Användardefinierade vägar med nästa hopptyp Virtuell nätverksgateway stöds inte för undernät i Routningsserverns virtuella nätverk och peerkopplade virtuella nätverk. Men om du vill konfigurera nästa hopp som en virtuell nätverksinstallation (NVA) eller Internet, stöds dock att lägga till en användardefinierad väg med nästa hopptyp VirtualAppliance eller Internet .
Varför har jag en användardefinierad väg (UDR) med nästa hopptyp inställd på Ingen i den virtuella datorns nätverksgränssnitts effektiva vägar?
Om du annonserar en väg från din NVA till routningsserver som är en exakt prefixmatchning som en annan användardefinierad väg måste nästa hopp för den annonserade vägen vara giltig. Om det annonserade nästa hoppet är en lastbalanserare utan en konfigurerad serverdelspool har den här ogiltiga vägen företräde framför den användardefinierade vägen. I nätverksgränssnittets effektiva vägar visas den ogiltiga annonserade vägen som en användardefinierad väg med nästa hopptyp inställd på Ingen.
Varför förlorar jag anslutningen efter att ha associerat en tjänstslutpunktsprincip med RouteServerSubnet eller GatewaySubnet?
Om du associerar en tjänstslutpunktsprincip med RouteServerSubnet eller GatewaySubnet kan kommunikationen brytas mellan Azures underliggande hanteringsplattform och dessa respektive Azure-tjänster (Routningsserver och VPN/ExpressRoute-gateway). Detta kan göra att dessa Azure-resurser anger ett feltillstånd, vilket resulterar i anslutningsförlust mellan dina lokala arbetsbelastningar och Azure-arbetsbelastningar.
Varför förlorar jag anslutningen när jag har använt anpassad DNS i stället för standardinställningen (Azure-tillhandahållen DNS) för routningsserverns virtuella nätverk?
Om du inte använder standard-DNS (Azure-tillhandahållen) för det virtuella nätverk som routningsservern distribueras i kontrollerar du att din anpassade DNS-konfiguration kan matcha offentliga domännamn. Detta säkerställer att Azure-tjänster (Route Server och VPN/ExpressRoute-gateway) kan kommunicera med Azures underliggande hanteringsplan. Mer information finns i anteckningen om jokerteckenregler i dokumentationen för Azure DNS Private Resolver.
Varför kan jag inte TCP-pinga från min NVA till BGP-peer-IP för routningsservern när jag har konfigurerat BGP-peering mellan dem?
I vissa NVA:er måste du lägga till en statisk väg till routningsserverns undernät för att kunna TCP pinga routningsservern från NVA och för att undvika BGP-peering. Om routningsservern till exempel är i 10.0.255.0/27 och din NVA är i 10.0.1.0/24, måste du lägga till följande väg till routningstabellen i NVA:
| Flöde | Nästa hopp |
|---|---|
| 10.0.255.0/27 | 10.0.1.1 |
10.0.1.1 är standardgatewayens IP-adress i undernätet där din NVA (eller mer exakt en av nätverkskorten) finns.
Varför förlorar jag anslutningen till mitt lokala nätverk via ExpressRoute och/eller Azure VPN när jag distribuerar en routningsserver till ett virtuellt nätverk som redan har ExpressRoute-gateway och/eller Azure VPN-gateway?
När du distribuerar en routningsserver till ett virtuellt nätverk måste vi uppdatera kontrollplanet mellan gatewayerna och det virtuella nätverket. Under den här uppdateringen finns det en tidsperiod då de virtuella datorerna i det virtuella nätverket förlorar anslutningen till det lokala nätverket. Vi rekommenderar starkt att du schemalägger underhåll för att distribuera en routningsserver i produktionsmiljön.
Problem med kontrollplan
Varför tar inte mitt lokala nätverk som är anslutet till Azure VPN-gatewayen emot standardvägen som annonseras av routningsservern?
Även om Azure VPN-gatewayen kan ta emot standardvägen från sina BGP-peer-datorer, inklusive routningsservern, annonseras inte standardvägen till andra peer-datorer.
Varför tar min NVA inte emot vägar från routningsservern trots att BGP-peeringen är igång?
Det ASN som routningsservern använder är 65515. Se till att du konfigurerar ett annat ASN för din NVA så att en eBGP-session kan upprättas mellan din NVA och Routningsserver så att routningsspridningen kan ske automatiskt. Se till att du aktiverar "multi-hop" i BGP-konfigurationen eftersom din NVA och routningsservern finns i olika undernät i det virtuella nätverket.
Varför fungerar inte anslutningen när jag annonserar vägar med ett ASN på 0 i AS-Path?
Azure Route Server släpper vägar med ett ASN på 0 i AS-Path. För att säkerställa att dessa vägar annonseras i Azure bör AS-Path inte innehålla 0.
BGP-peering mellan min NVA och Route Server är igång. Jag kan se vägar som utbyts korrekt mellan dem. Varför finns inte NVA-vägarna i den effektiva routningstabellen för min virtuella dator?
Om den virtuella datorn finns i samma virtuella nätverk som din NVA och routningsserver:
Routningsservern exponerar två BGP-peer-IP-adresser som delar ansvaret för att skicka vägarna till alla andra virtuella datorer som körs i det virtuella nätverket. Varje NVA måste konfigurera två identiska BGP-sessioner (till exempel använda samma AS-nummer, samma AS-sökväg och annonsera samma uppsättning vägar) till de två BGP-peer-IP-adresserna så att dina virtuella datorer i det virtuella nätverket kan få konsekvent routningsinformation från Azure Route Server.
Om du har två eller flera instanser av NVA kan du annonsera olika AS-sökvägar för samma väg från olika NVA-instanser om du vill ange en NVA-instans som aktiv och den andra passiv.
Om den virtuella datorn finns i ett annat virtuellt nätverk än den som är värd för din NVA och routningsservern. Kontrollera om VNet-peering är aktiverat mellan de två virtuella nätverken och om Använd fjärrvägsserver är aktiverat i den virtuella datorns virtuella nätverk.
Varför är ECMP-funktionen (Equal-Cost Multi-Path) inaktiverad för min ExpressRoute när jag har distribuerat Route Server till det virtuella nätverket?
När du annonserar samma vägar från ditt lokala nätverk till Azure via flera ExpressRoute-anslutningar är ECMP normalt aktiverat som standard för trafiken som är avsedd för dessa vägar från Azure tillbaka till ditt lokala nätverk. När du distribuerar routningsservern går för närvarande information med flera sökvägar förlorad i BGP-utbytet mellan ExpressRoute och routningsservern, och därför passerar trafiken från Azure endast på en av ExpressRoute-anslutningarna.
Driftproblem
Varför visas ett fel om ogiltigt omfång och auktorisering för att utföra routningsserveråtgärder?
Om du ser ett fel i formatet nedan kontrollerar du att du har följande behörigheter konfigurerade: Routningsserverroller och -behörigheter
Felmeddelandeformat: "Klienten med objekt-ID {} har inte behörighet att utföra åtgärder {} över omfång {} eller omfånget är ogiltigt. Om åtkomst nyligen beviljats kan du uppdatera dina autentiseringsuppgifter.”
Gå vidare
Information om hur du skapar och konfigurerar Azure Route Server finns i: