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 een direct effect op de prestaties van toepassingen en de gebruikerservaring. Dit artikel illustreert dit probleem en legt uit hoe u routering optimaliseert met behulp van de standaardrouteringstechnologieën.

Padselectie voor Microsoft- en openbare peering

Het is belangrijk om ervoor te zorgen dat bij het gebruik van Microsoft- of openbare peering 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 padselectie-algoritme op basis van veel factoren, waaronder LPM (langste voorvoegselovereenkomst). Om ervoor te zorgen dat verkeer dat is bestemd voor Azure via Microsoft of openbare peering het ExpressRoute-pad passeert, moet u het kenmerk Local Preference 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.

Bekijk het volgende voorbeeldscenario:

Als u in het bovenstaande voorbeeld de voorkeur wilt geven aan ExpressRoute-paden, configureert u Lokale voorkeur als volgt.

Cisco IOS-XE-configuratie vanuit R1-perspectief:

• R1(config)#route-kaart 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 activeren

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

Junos-configuratie vanuit het perspectief van R1:

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

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. Het is uw bedoeling 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 adverteert dat gebruikers in elk kantoor toegang hebben tot de nabijgelegen Azure-services voor optimale ervaringen. Het plan werkt goed voor de gebruikers van de oostkust, maar niet voor de gebruikers van de westkust.

De oorzaak van het probleem ligt in elk ExpressRoute-circuit. We adverteren 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 uit welke regio komt, kunt u dit 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 hebt u veel ongelukkige gebruikers in het kantoor in 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 de 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 de klant naar het virtuele Azure-netwerk bij het gebruik van persoonlijke peering. Microsoft tagt geen BGP-communitywaarden aan de voorvoegsels die vanuit Azure naar uw netwerk worden geadverteerd. Omdat 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 het ene ExpressRoute-circuit boven het andere.

Suboptimale routering van Microsoft naar de klant

In dit voorbeeld hebben we verbindingen van Microsoft een langer pad nodig 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 aan 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 doorgestuurd 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 welk voorvoegsel 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 uw on-premises voorvoegsel voor uw kantoor in Los Angeles 177.2.0.0/31 op het ExpressRoute-circuit in US - west adverteert. 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 kunt 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 US - oost, zodat 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, 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 bij peering met behulp van een privé-AS-nummer. U moet peeren met een openbare AS en openbare AS-nummers toevoegen aan het AS-PAD om de routering voor Microsoft-peering te beïnvloeden.

Notitie

Hoewel de hier getoonde voorbeelden voor Microsoft- en openbare peerings zijn, ondersteunen we dezelfde mogelijkheden voor 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 te zien is 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. Aangezien ECMP-routering (Equal-Cost-Multi-Path) wordt gebruikt om verkeer tussen VNet's te verdelen, nemen sommige verkeersstromen het langere pad en worden ze gerouteerd via 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 voor dat voorvoegsel is bestemd.

Notitie

U kunt ook de 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 wordt beschreven in het tweede scenario. 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.