ExpressRoute-routering optimaliseren

Als u meerdere ExpressRoute-circuits hebt, hebt u meer dan één pad om verbinding te maken met Microsoft. Dat betekent dat suboptimale routering kan plaatsvinden, met andere woorden, dat verkeer soms een langer pad aflegt om Microsoft te bereiken en Microsoft om uw netwerk te bereiken. Hoe langer het netwerkpad, hoe groter de latentie. Latentie heeft direct effect op de prestaties van toepassingen en gebruikerservaring. In dit artikel wordt dit probleem geïllustreerd en wordt uitgelegd hoe u routering optimaliseert met behulp van de standaardrouteringstechnologieën.

Padselectie voor Microsoft-peering

Het is belangrijk om ervoor te zorgen dat wanneer u Microsoft gebruikt dat verkeer via het gewenste pad stroomt als u een of meer ExpressRoute-circuits hebt. U moet er ook voor zorgen dat paden naar internet een Internet Exchange (IX) of internetprovider (ISP) gebruiken. BGP maakt gebruik van een beste algoritme voor padselectie op basis van veel factoren, waaronder langste voorvoegselovereenkomst (LPM). Om ervoor te zorgen dat verkeer dat is bestemd voor Azure via Microsoft het ExpressRoute-pad doorkruist, moet u het kenmerk Lokale voorkeur implementeren. Deze instelling zorgt ervoor dat het pad altijd de voorkeur heeft op ExpressRoute.

Notitie

De standaard lokale voorkeur is doorgaans 100. Hogere lokale voorkeuren hebben de voorkeur.

Overweeg het volgende voorbeeldscenario:

In het bovenstaande voorbeeld kunt u de voorkeur geven aan ExpressRoute-paden om lokale voorkeur als volgt te configureren.

Cisco IOS-XE-configuratie vanuit R1 perspectief:

• R1(config)#route-map prefer-ExR permit 10

• R1(config-route-map)#set lokale voorkeur 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 activeren

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

Junos-configuratie vanuit R1 perspectief:

• user@R1# protocollen bgp groep ibgp type intern
• user@R1# protocollen bgp groep ibgp local-preference 150

Suboptimale routering van klant naar Microsoft

We gaan het routeringsprobleem bekijken aan de hand van een voorbeeld. Stel, u hebt twee kantoren in de VS, één in Los Angeles en één in New York. Uw kantoren zijn aangesloten op een Wide Area Network (WAN). Dit kan uw eigen backbone-netwerk zijn of het IP VPN van uw serviceprovider. U hebt twee ExpressRoute-circuits, één in US - west en één in US - oost. Beide zijn ook verbonden op het WAN. U hebt uiteraard twee paden om verbinding te maken met het Microsoft-netwerk.

Stel nu dat u een Azure-implementatie hebt, bijvoorbeeld een Azure-app-service in zowel US - west als US - oost. Uw bedoeling is om uw gebruikers in Los Angeles te verbinden met Azure US - west en uw gebruikers in New York met Azure US - oost. De reden voor deze instelling is dat uw servicebeheerder adverteren dat gebruikers in elk kantoor toegang hebben tot de nabijgelegen Azure-services voor optimale ervaringen. Het plan werkt goed voor de gebruikers aan de oostkust, maar niet voor de gebruikers van de westkust.

De oorzaak van het probleem is op elk ExpressRoute-circuit. We adverteren naar on-premises zowel het voorvoegsel in Azure US - oost 23.100.0.0/16 als het voorvoegsel in Azure US - west 13.100.0.0/16. Als u niet weet welk voorvoegsel afkomstig is uit welke regio, kunt u het niet anders behandelen. Misschien 'denkt' uw WAN-netwerk dat beide voorvoegsels zich dichter bij US - oost bevinden dan bij US - west, en worden de gebruikers van beide kantoren daarom omgeleid naar het ExpressRoute-circuit in US - oost. Uiteindelijk heb je veel ongelukkige gebruikers in het kantoor van Los Angeles.

Oplossing: gebruik BGP-community's

Om routering te optimaliseren voor de gebruikers op beide kantoren, moet u weten welk voorvoegsel van Azure US - west is en welk van Azure US - oost. Deze informatie wordt versleuteld met BGP-communitywaarden. We hebben een unieke BGP-communitywaarde toegewezen aan elke Azure-regio, bijvoorbeeld 12076:51004 voor US - oost, 12076:51006 voor US - west. Nu u weet welk voorvoegsel bij welke Azure-regio hoort, kunt u configureren welk ExpressRoute-circuit de voorkeur heeft. Omdat we de BGP gebruiken om routeringsgegevens uit te wisselen, kunt u de lokale voorkeur van BGP gebruiken om routering te beïnvloeden.

In ons voorbeeld kunt u in US - west aan 13.100.0.0/16 een hogere lokale-voorkeurswaarde toekennen dan in US - oost, en in US - oost kunt u aan 23.100.0.0/16 een hogere lokale-voorkeurswaarde toekennen dan in US - west. Deze configuratie zorgt ervoor dat, wanneer beide paden naar Microsoft beschikbaar zijn, uw gebruikers in Los Angeles het ExpressRoute-circuit in US - west gebruiken om verbinding te maken met Azure US - west, terwijl uw gebruikers in New York de ExpressRoute in US - oost naar Azure US - oost nemen. Routering is nu aan beide zijden geoptimaliseerd.

Notitie

Dezelfde techniek, met behulp van lokale voorkeur, kan worden toegepast op routering van klant naar virtueel Azure-netwerk bij gebruik van persoonlijke peering. Microsoft tagt geen BGP-communitywaarden naar de voorvoegsels die van Azure naar uw netwerk worden aangekondigd. Aangezien u echter weet welke van uw virtuele netwerkimplementatie zich dicht bij welk van uw kantoor bevindt, kunt u uw routers dienovereenkomstig configureren om de voorkeur te geven aan één ExpressRoute-circuit via een ander.

Suboptimale routering van Microsoft naar de klant

In dit voorbeeld hebben we verbindingen van Microsoft een langer pad om uw netwerk te bereiken. In dit geval maakt u gebruik van on-premises Exchange-servers en Exchange Online in een hybride omgeving. Uw kantoren zijn verbonden met een WAN. U adverteert de voorvoegsels van uw on-premises servers in beide kantoren naar Microsoft via twee ExpressRoute-circuits.

Exchange Online initieert verbindingen met de on-premises servers in gevallen zoals postvakmigratie. De verbinding met uw kantoor in Los Angeles wordt gerouteerd naar het ExpressRoute-circuit in US - oost voordat u het hele continent weer doorkruist naar de westkust. De oorzaak van het probleem is vergelijkbaar met die in het eerste voorbeeld. Zonder enige hint kan het Microsoft-netwerk niet zien welk on-premises voorvoegsel zich dicht bij US - oost bevindt en welke zich dicht bij US - west bevindt. Dus soms wordt het verkeerde pad naar uw kantoor in Los Angeles gekozen.

Oplossing: AS-padtoevoeging

Er zijn twee oplossingen voor het probleem. De eerste is dat u gewoon uw on-premises voorvoegsel voor uw Los Angeles-kantoor 177.2.0.0/31 op het ExpressRoute-circuit in US - west adverteren. Vervolgens adverteert u uw on-premises voorvoegsel voor uw kantoor in New York, 177.2.0.2/31 op het ExpressRoute-circuit in US - oost. Als gevolg hiervan is er slechts één pad voor Microsoft om verbinding te maken met elk van uw kantoren. Er is geen dubbelzinnigheid en routering is geoptimaliseerd. Bij dit ontwerp moet u echter nadenken over een failoverstrategie. Als het pad naar Microsoft via ExpressRoute uitvalt, moet u ervoor zorgen dat Exchange Online nog steeds verbinding kan maken met uw on-premises servers.

Voor de tweede oplossing blijft u beide voorvoegsels op beide ExpressRoute-circuits adverteren en geeft u daarnaast aan welk voorvoegsel zich het dichtst bij welk kantoor bevindt. Omdat we BGP AS-padtoevoeging ondersteunen, kunt u het AS-pad voor uw voorvoegsel configureren om routering te beïnvloeden. In dit voorbeeld kunt u het AS-PAD voor 172.2.0.0/31 in VS - oost zo lang maken dat we de voorkeur geven aan het ExpressRoute-circuit in US - west voor verkeer dat is bestemd voor dit voorvoegsel. Op dezelfde manier kunt u het AS-PAD voor 172.2.0.2/31 in US - west langer maken, zodat we de voorkeur geven aan het ExpressRoute-circuit in US - oost. Routering is geoptimaliseerd voor beide kantoren. Als bij dit ontwerp één ExpressRoute-circuit wordt verbroken, kan Exchange Online u nog steeds bereiken via een ander ExpressRoute-circuit en uw WAN.

Belangrijk

We verwijderen persoonlijke AS-nummers in het AS-PAD voor de voorvoegsels die zijn ontvangen op Microsoft-peering wanneer peering een privé-AS-nummer gebruikt. U moet peeren met een openbare AS en openbare AS-nummers toevoegen in het AS-PAD om routering voor Microsoft-peering te beïnvloeden.

Notitie

Hoewel de voorbeelden die hier worden gegeven voor Microsoft-peering, ondersteunen we dezelfde mogelijkheden voor de persoonlijke peering. De AS-padtoevoeging werkt ook binnen één ExpressRoute-circuit om de selectie van primaire en secundaire paden te beïnvloeden.

Suboptimale routering tussen virtuele netwerken

Met ExpressRoute kunt u VNet-communicatie (communicatie van Virtual Network naar Virtual Network) inschakelen door de VNets te koppelen aan een ExpressRoute-circuit. Wanneer u ze koppelt aan meerdere ExpressRoute-circuits, kan er suboptimale routering tussen de VNets optreden. Een voorbeeld. U hebt twee ExpressRoute-circuits, één in US - west en één in US - oost. In elke regio hebt u twee VNets. Uw webservers zijn geïmplementeerd in het ene VNet en de toepassingsservers in het andere. Ten behoeve van redundantie kunt u de twee VNets in elke regio koppelen aan zowel het lokale ExpressRoute-circuit als aan het externe ExpressRoute-circuit. Zoals u kunt zien in het volgende diagram, zijn er vanuit elk VNet twee paden naar het andere VNet. De VNets weten niet welk ExpressRoute-circuit lokaal is en welk circuit extern. Omdat ECMP-routering (Equal-Cost-Multi-Path) wordt gebruikt om verkeer tussen VNet's te verdelen, nemen sommige verkeersstromen het langere pad in en worden ze gerouteerd op het externe ExpressRoute-circuit.

Oplossing: meer gewicht toewijzen aan lokale verbinding

De oplossing is eenvoudig. Omdat u weet waar de VNets en circuits zich bevinden, kunt u ons vertellen aan welk pad elke VNet de voorkeur moet geven. Voor dit voorbeeld wijst u aan de lokale verbinding een hoger gewicht toe dan aan de externe verbinding (klik hier voor een configuratievoorbeeld). Wanneer een VNet het voorvoegsel van het andere VNet op meerdere verbindingen ontvangt, geeft het de voorkeur aan de verbinding met het hoogste gewicht om verkeer te verzenden dat is bestemd voor dat voorvoegsel.

Notitie

U kunt ook routering van VNet naar uw on-premises netwerk beïnvloeden, als u meerdere ExpressRoute-circuits hebt, door het gewicht van een verbinding te configureren in plaats van AS PATH-prepending toe te passen, een techniek die in het tweede scenario wordt beschreven. Wanneer er wordt bepaald hoe het verkeer moet worden verzonden, wordt er voor elk voorvoegsel altijd eerst gekeken naar het gewicht van de verbinding en dan pas naar de AS PATH-lengte.

Volgende stappen

• Meer informatie over het ontwerpen van ExpressRoute voor hoge beschikbaarheid.
• Meer informatie over het ontwerpen van ExpressRoute voor herstel na noodgevallen.