Optimera ExpressRoute-routning

När du har flera ExpressRoute-kretsar måste ha du mer än en sökväg för att ansluta till Microsoft. Därför kan en icke-optimal routning inträffa - vilket innebär att din trafik får en längre sökväg till Microsoft, och Microsoft till nätverket. Ju längre nätverkssökvägen är, desto längre svarstid. Svarstiden har direkt effekt på programmets prestanda och användarupplevelse. Den här artikeln illustrerar det här problemet och förklarar hur du optimerar routning med hjälp av standarddirigeringsteknikerna.

Sökvägsval för Microsoft-peering

Det är viktigt att se till att trafiken flödar över önskad sökväg när du använder Microsoft om du har en eller flera ExpressRoute-kretsar. Du måste också se till att sökvägar till Internet använder en Internet Exchange (IX) eller Internetleverantör (ISP). BGP använder en algoritm för bästa sökvägsval baserat på många faktorer, inklusive den längsta prefixmatchning (LPM). För att säkerställa att trafik som är avsedd för Azure via Microsoft passerar ExpressRoute-sökvägen måste du implementera attributet Lokal inställning . Den här inställningen säkerställer att sökvägen alltid föredras på ExpressRoute.

Kommentar

Den lokala standardinställningen är vanligtvis 100. Högre lokala inställningar är mer föredragna.

Föreställ dig följande exempel:

I exemplet ovan kan du föredra att ExpressRoute-sökvägar konfigurerar lokala inställningar på följande sätt.

Cisco IOS-XE-konfiguration från R1-perspektiv:

• 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 aktivera

• R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in

Junos-konfiguration från R1-perspektiv:

• user@R1# set protocols bgp group ibgp type internal
• user@R1# set protocols bgp group ibgp local-preference 150

Icke-optimal routning från kund till Microsoft

Låt oss titta närmare på routningsproblemet med ett exempel. Anta att du har två kontor i USA, ett i Los Angeles och ett i New York. Ditt kontor ansluts i ett WAN (Wide Area Network), som kan vara antingen ditt eget stamnät eller leverantörens IP VPN. Anta att du har två ExpressRoute-kretsar, en i ”USA, västra” och en i ”USA, östra”. Båda är också anslutna på WAN. Naturligtvis har du två sökvägar för att ansluta till Microsoft-nätverket.

Anta nu att du har en Azure-distribution, till exempel en Azure App Service i både USA, västra och USA, östra. Din avsikt är att ansluta dina användare i Los Angeles till Azure USA, västra och dina användare i New York till Azure USA, östra. Orsaken till den här konfigurationen är att tjänstadministratören annonserar att användare på varje kontor får åtkomst till de närliggande Azure-tjänsterna för optimala upplevelser. Planen fungerar bra för östkustanvändare men inte för västkustanvändare.

Orsaken till problemet finns på varje ExpressRoute-krets, vi annonserar till lokala både prefixet i Azure US East 23.100.0.0/16 och prefixet i Azure US West 13.100.0.0/16. Om du inte vet vilket prefix som är från vilken region kan du inte behandla det annorlunda. WAN-nätverket kan tro att båda prefixen är närmare USA, östra än USA, västra och därför dirigera båda kontorens användare till ExpressRoute-kretsen i USA, östra. I slutändan har du många missnöjda användare på Los Angeles-kontoret.

Lösning: Använd BGP-communities

För att optimera routningen för båda kontoren måste du veta vilket prefix som är från Azure i USA, västra och vilket som är från Azure i USA, östra. Vi kodar informationen genom att använda BGP Community-värden. Vi har tilldelat ett unikt BGP Community-värde till varje Azure-region, till exempel 12076:51004 för USA, östra, för USA, 12076:51006 västra. Nu när du vet vilket prefix är från vilken Azure-region, kan du konfigurera de ExpressRoute-kretsar som ska användas. Eftersom vi använder BGP för att utbyta routningsinformation kan du använda BGP:s lokala inställningar för att påverka routning.

I vårt exempel kan du tilldela ett högre lokalt inställningsvärde för 13.100.0.0/16 i USA, västra än i USA, östra och på samma sätt ett högre lokalt inställningsvärde för 23.100.0.0/16 i USA, östra än i USA, västra. Den här konfigurationen ser till att när båda sökvägarna till Microsoft är tillgängliga tar användarna i Los Angeles ExpressRoute-kretsen i USA, västra för att ansluta till Azure USA, västra medan användarna i New York tar ExpressRoute i USA, östra till Azure USA, östra. Routning är optimerad på båda sidorna.

Kommentar

Samma teknik, med hjälp av lokala inställningar, kan tillämpas på routning från kund till virtuellt Azure-nätverk när du använder privat peering. Microsoft taggar inte BGP-communityvärden till prefixen som annonseras från Azure till nätverket. Men eftersom du vet vilken av distributionen av det virtuella nätverket som ligger nära vilket kontor du har kan du konfigurera routrarna så att de föredrar en ExpressRoute-krets framför en annan.

Icke-optimal routning från Microsoft till kund

I det här exemplet har vi anslutningar från Microsoft som tar längre tid att nå nätverket. I detta fall måste du använda lokala Exchange-servrar och Exchange Online i en hybridmiljö. Dina kontor är anslutna till ett WAN-nätverk. Du annonserar prefixen för dina lokala servrar på båda kontoren till Microsoft via två ExpressRoute-kretsar.

Exchange Online initierar anslutningar till de lokala servrarna i fall som postlådemigrering. Anslutningen till ditt Los Angeles-kontor dirigeras till ExpressRoute-kretsen i USA, östra innan du passerar hela kontinenten tillbaka till västkusten. Orsaken till problemet liknar det första fallet. Utan tips kan Microsoft-nätverket inte avgöra vilket lokalt prefix som ligger nära USA, östra och vilket som ligger nära USA, västra. Det råkar välja fel sökväg till kontoret i Los Angeles.

Lösning: Använd AS PATH

Det finns två lösningar på problemet. Den första är att du bara annonserar ditt lokala prefix för ditt Los Angeles-kontor 177.2.0.0/31 på ExpressRoute-kretsen i USA, västra. Sedan annonserar du ditt lokala prefix för ditt New York-kontor, 177.2.0.2/31 på ExpressRoute-kretsen i USA, östra. Därför finns det bara en sökväg för Microsoft att ansluta till vart och ett av dina kontor. Det finns ingen tvetydighet och routning är optimerad. Du måste tänka på din redundansstrategi med den här designen. Om sökvägen till Microsoft via ExpressRoute slutar fungera måste du se till att Exchange Online fortfarande kan ansluta till dina lokala servrar.

Den andra lösningen är att du fortsätter att annonsera båda prefixen för båda ExpressRoute-kretsarna, men dessutom ger du oss en ledtråd för vilka prefix som ligger nära dina kontor. Du kan konfigurera AS PATH för ditt prefix om du vill påverka routningen eftersom vi stöder BGP. I det här exemplet kan du förlänga AS PATH för 172.2.0.0/31 i USA, östra så att vi föredrar ExpressRoute-kretsen i USA, västra för trafik som är avsedd för det här prefixet. På samma sätt kan du förlänga AS PATH för 172.2.0.2/31 i USA, västra så att vi föredrar ExpressRoute-kretsen i USA, östra. Routning är optimerat för båda kontoren. Med den här designen kan Exchange Online fortfarande nå dig via en annan ExpressRoute-krets och ditt WAN om en ExpressRoute-krets bryts.

Viktigt!

Vi tar bort privata AS-nummer i AS PATH för de prefix som tas emot på Microsoft Peering vid peering med ett privat AS-nummer. Du måste peerkoppla med ett offentligt AS och lägga till offentliga AS-nummer i AS PATH för att påverka routning för Microsoft-peering.

Kommentar

Exemplen som ges här är för Microsoft-peering, men vi stöder samma funktioner för privat peering. Dessutom fungerar AS Path-prepending inom en enda ExpressRoute-krets för att påverka valet av primära och sekundära sökvägar.

Icke-optimal routning mellan virtuella nätverk

Med ExpressRoute kan du använda ”virtuellt nätverk till virtuellt nätverk”-kommunikation (vilket även kallas ”VNet”) genom att länka dem till en ExpressRoute-krets. När du länkar de virtuella nätverken till flera ExpressRoute-kretsar kan icke-optimal routning uppstå mellan dem. Vi tar ett exempel. Anta att du har två ExpressRoute-kretsar, en i ”USA, västra” och en i ”USA, östra”. Du har två virtuella nätverk i varje region. Webbservrar distribueras i det ena virtuella nätverket och programservrar i det andra. För redundans länkar du de två virtuella nätverken i varje region till både den lokala ExpressRoute-kretsen och ExpressRoute-fjärrkretsen. Som du ser i följande diagram finns det två sökvägar till det andra virtuella nätverket från varje virtuellt nätverk. De virtuella nätverken vet inte vilken ExpressRoute-krets som är den lokala kretsen och vilken som är fjärrkretsen. Eftersom ECMP-routning (Equal-Cost-Multi-Path) används för att belastningsutjämna trafik mellan virtuella nätverk tar vissa trafikflöden den längre vägen och dirigeras till expressroute-fjärrkretsen.

Lösning: Tilldela en hög vikt till den lokala anslutningen

Lösningen är enkel. Eftersom du vet var de virtuella nätverken och kretsarna är kan du berätta för oss vilken väg som varje virtuella nätverk ska prioritera. För just det här fallet tilldelar du en högre vikt till den lokala anslutningen än till fjärranslutningen (du hittar konfigurationsexemplet här). När ett virtuellt nätverk tar emot prefixet för det andra virtuella nätverket på flera anslutningar föredrar det att anslutningen med den högsta vikten skickar trafik som är avsedd för prefixet.

Kommentar

Du kan också påverka routning från VNet till ditt lokala nätverk, om du har flera ExpressRoute-kretsar genom att konfigurera vikten för en anslutning i stället för att tillämpa AS PATH-prepending, en teknik som beskrivs i det andra scenariot. För varje prefix tittar vi alltid på anslutningsvikten före AS Path-längden när vi avgör hur trafiken ska skickas.

Nästa steg

• Lär dig mer om att utforma ExpressRoute för hög tillgänglighet.
• Lär dig mer om att utforma ExpressRoute för haveriberedskap.