ExpressRoute-routering optimaliserenOptimize ExpressRoute Routing

Als u meerdere ExpressRoute-circuits hebt, hebt u meer dan één pad om verbinding te maken met Microsoft.When you have multiple ExpressRoute circuits, you have more than one path to connect to 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.As a result, suboptimal routing may happen - that is, your traffic may take a longer path to reach Microsoft, and Microsoft to your network. Hoe langer het netwerkpad, hoe groter de latentie.The longer the network path, the higher the latency. Latentie heeft een directe invloed op toepassingsprestaties en gebruikerservaring.Latency has direct impact on application performance and user experience. In dit artikel wordt dit probleem geïllustreerd en wordt uitgelegd hoe u routering optimaliseert met behulp van de standaardrouteringstechnologieën.This article will illustrate this problem and explain how to optimize routing using the standard routing technologies.

Padselectie op micro soft en open bare peeringsPath Selection on Microsoft and Public peerings

Het is belang rijk om ervoor te zorgen dat bij gebruik van micro soft of open bare peering dat verkeer over het gewenste pad loopt als u een of meer ExpressRoute-circuits hebt, evenals paden naar het Internet via een Internet Exchange (IX) of Internet service provider (ISP).It's important to ensure that when utilizing Microsoft or Public peering that traffic flows over the desired path if you have one or more ExpressRoute circuits, as well as paths to the Internet via an Internet Exchange (IX) or Internet Service Provider (ISP). BGP gebruikt een selectie algoritme voor het beste pad op basis van een aantal factoren, waaronder de langste voorvoegsel overeenkomst (LPM).BGP utilizes a best path selection algorithm based on a number of factors including longest prefix match (LPM). Klanten moeten het lokale voorkeurs kenmerk implementeren om ervoor te zorgen dat verkeer dat is bestemd voor Azure via micro soft of open bare peering over het ExpressRoute-pad, zodat het pad altijd de voor keur heeft voor ExpressRoute.To ensure that traffic destined for Azure via Microsoft or Public peering traverses the ExpressRoute path, customers must implement the Local Preference attribute to ensure that the path is always preferred on ExpressRoute.

Notitie

De standaard lokale voor keur is doorgaans 100.The default local preference is typically 100. Hogere lokale voor keuren zijn meer voor keur.Higher local preferences are more preferred.

Bekijk het volgende voorbeeld scenario:Consider the following example scenario:

Probleem ExpressRoute casus 1: Suboptimale routering van klant naar Microsoft

In het bovenstaande voor beeld kunt u de lokale voor keur als volgt configureren in ExpressRoute-paden.In the above example, to prefer ExpressRoute paths configure Local Preference as follows.

Cisco IOS-XE-configuratie van R1-perspectief:Cisco IOS-XE configuration from R1 perspective:

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 activate
R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in

Junos-configuratie van R1 perspectief:Junos configuration from R1 perspective:

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

Suboptimale routering van klant naar MicrosoftSuboptimal routing from customer to Microsoft

We gaan het routeringsprobleem bekijken aan de hand van een voorbeeld.Let's take a close look at the routing problem by an example. Stel, u hebt twee kantoren in de VS, één in Los Angeles en één in New York.Imagine you have two offices in the US, one in Los Angeles and one 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.Your offices are connected on a Wide Area Network (WAN), which can be either your own backbone network or your service provider's IP VPN. U hebt twee ExpressRoute-circuits, één in US - west en één in US - oost. Deze zijn ook aangesloten op het WAN.You have two ExpressRoute circuits, one in US West and one in US East, that are also connected on the WAN. U hebt uiteraard twee paden om verbinding te maken met het Microsoft-netwerk.Obviously, you have two paths to connect to the Microsoft network. Stel nu dat u zowel in US - west als in US - oost een Azure-implementatie hebt (bijvoorbeeld Azure App Service).Now imagine you have Azure deployment (for example, Azure App Service) in both US West and US East. 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, omdat uw servicebeheerder adverteert dat gebruikers in elk kantoor voor optimale ervaringen gebruik kunnen maken van de Azure-services die zich zo dichtbij mogelijk bevinden.Your intention is to connect your users in Los Angeles to Azure US West and your users in New York to Azure US East because your service admin advertises that users in each office access the nearby Azure services for optimal experiences. Helaas werkt dit plan prima voor de gebruikers aan de oostkust maar niet voor de gebruikers aan de westkust.Unfortunately, the plan works out well for the east coast users but not for the west coast users. Dit heeft de volgende oorzaak.The cause of the problem is the following. In elk ExpressRoute-circuit adverteren we aan u zowel het voorvoegsel in Azure US - oost (23.100.0.0/16) als het voorvoegsel in Azure US - west (13.100.0.0/16).On each ExpressRoute circuit, we advertise to you both the prefix in Azure US East (23.100.0.0/16) and the prefix in Azure US West (13.100.0.0/16). Als u niet weet welk voorvoegsel bij welke regio hoort, kunt u ze niet op verschillende manieren behandelen.If you don't know which prefix is from which region, you are not able to treat it differently. 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.Your WAN network may think both of the prefixes are closer to US East than US West and therefore route both office users to the ExpressRoute circuit in US East. Dit leidt tot veel ontevreden gebruikers in het kantoor in Los Angeles.In the end, you will have many unhappy users in the Los Angeles office.

Probleem ExpressRoute casus 1: Suboptimale routering van klant naar Microsoft

Oplossing: gebruik BGP-community'sSolution: use BGP Communities

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.To optimize routing for both office users, you need to know which prefix is from Azure US West and which from Azure US East. Deze informatie wordt versleuteld met BGP-communitywaarden.We encode this information by using BGP Community values. Aan elke Azure-regio is een unieke BGP-communitywaarde toegewezen, bijvoorbeeld '12076:51004' voor US - oost en '12076:51006' voor US - west.We've assigned a unique BGP Community value to each Azure region, e.g. "12076:51004" for US East, "12076:51006" for US West. Nu u weet welk voorvoegsel bij welke Azure-regio hoort, kunt u configureren welk ExpressRoute-circuit de voorkeur heeft.Now that you know which prefix is from which Azure region, you can configure which ExpressRoute circuit should be preferred. Omdat we het BGP gebruiken om routeringsinformatie uit te wisselen, kunt u de routering beïnvloeden met de lokale voorkeur van het BGP.Because we use the BGP to exchange routing info, you can use BGP's Local Preference to influence routing. 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.In our example, you can assign a higher local preference value to 13.100.0.0/16 in US West than in US East, and similarly, a higher local preference value to 23.100.0.0/16 in US East than in US West. Als beide paden naar Microsoft beschikbaar zijn, zorgt deze configuratie ervoor dat uw gebruikers in Los Angeles het ExpressRoute-circuit in US - west gebruiken om verbinding te maken met Azure US - west, en uw gebruikers in New York de ExpressRoute in US - oost nemen naar Azure US - oost.This configuration will make sure that, when both paths to Microsoft are available, your users in Los Angeles will take the ExpressRoute circuit in US West to connect to Azure US West whereas your users in New York take the ExpressRoute in US East to Azure US East. Routering is nu aan beide zijden geoptimaliseerd.Routing is optimized on both sides.

Oplossing Expressroute casus 1: BGP-community's gebruiken

Notitie

Dezelfde techniek, het gebruik van lokale voorkeur, kan ook worden toegepast op routering van klant naar Azure Virtual Network.The same technique, using Local Preference, can be applied to routing from customer to Azure Virtual Network. We voegen geen BGP Community-waarde toe aan de voorvoegsels die vanuit Azure zijn aangekondigd aan uw netwerk.We don't tag BGP Community value to the prefixes advertised from Azure to your network. Maar omdat u weet welke Virtual Network-implementatie zich dicht bij uw kantoor bevindt, kunt u uw routers zo configureren dat het ene ExpressRoute-circuit de voorkeur krijgt boven het andere.However, since you know which of your Virtual Network deployment is close to which of your office, you can configure your routers accordingly to prefer one ExpressRoute circuit to another.

Suboptimale routering van Microsoft naar de klantSuboptimal routing from Microsoft to customer

Hier volgt nog een voorbeeld waarin verbindingen van Microsoft een langer pad afleggen om uw netwerk te bereiken.Here is another example where connections from Microsoft take a longer path to reach your network. In dit geval maakt u gebruik van on-premises Exchange-servers en Exchange Online in een hybride omgeving.In this case, you use on-premises Exchange servers and Exchange Online in a hybrid environment. Uw kantoren zijn verbonden met een WAN.Your offices are connected to a WAN. U adverteert de voorvoegsels van uw on-premises servers in beide kantoren aan Microsoft door middel van de twee ExpressRoute-circuits.You advertise the prefixes of your on-premises servers in both of your offices to Microsoft through the two ExpressRoute circuits. Voor bijvoorbeeld postvakmigratie start Exchange Online verbindingen met de on-premises servers.Exchange Online will initiate connections to the on-premises servers in cases such as mailbox migration. Helaas wordt de verbinding met uw kantoor in Los Angeles omgeleid naar het ExpressRoute-circuit in US - oost, waarna deze het gehele continent doorkruist om weer aan de westkust uit te komen.Unfortunately, the connection to your Los Angeles office is routed to the ExpressRoute circuit in US East before traversing the entire continent back to the west coast. De oorzaak van het probleem is vergelijkbaar met die in het eerste voorbeeld.The cause of the problem is similar to the first one. Zonder aanwijzingen weet het Microsoft-netwerk niet welk klantvoorvoegsel zich dichter bij US - oost bevindt en welk dichter bij US - west.Without any hint, the Microsoft network can't tell which customer prefix is close to US East and which one is close to US West. Dus soms wordt het verkeerde pad naar uw kantoor in Los Angeles gekozen.It happens to pick the wrong path to your office in Los Angeles.

Probleem ExpressRoute casus 2: Suboptimale routering van Microsoft naar de klant

Oplossing: AS-padtoevoegingSolution: use AS PATH prepending

Er zijn twee oplossingen voor het probleem.There are two solutions to the problem. Voor de eerste oplossing adverteert u gewoon het on-premises voorvoegsel voor uw kantoor in Los Angeles, 177.2.0.0/31, op het ExpressRoute-circuit in US - west en het on-premises voorvoegsel voor uw kantoor in New York, 177.2.0.2/31, op het ExpressRoute-circuit in US - oost.The first one is that you simply advertise your on-premises prefix for your Los Angeles office, 177.2.0.0/31, on the ExpressRoute circuit in US West and your on-premises prefix for your New York office, 177.2.0.2/31, on the ExpressRoute circuit in US East. Als gevolg hiervan is er slechts één pad waarlangs Microsoft verbinding maakt met elk kantoor.As a result, there is only one path for Microsoft to connect to each of your offices. Er is geen dubbelzinnigheid en routering is geoptimaliseerd.There is no ambiguity and routing is optimized. Bij dit ontwerp moet u echter nadenken over een failoverstrategie.With this design, you need to think about your failover strategy. Als het pad naar Microsoft via ExpressRoute wordt verbroken, moet u ervoor zorgen dat Exchange Online nog steeds verbinding kan maken met uw on-premises servers.In the event that the path to Microsoft via ExpressRoute is broken, you need to make sure that Exchange Online can still connect to your 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.The second solution is that you continue to advertise both of the prefixes on both ExpressRoute circuits, and in addition you give us a hint of which prefix is close to which one of your offices. Omdat we BGP AS-padtoevoeging ondersteunen, kunt u het AS-pad voor uw voorvoegsel configureren om routering te beïnvloeden.Because we support BGP AS Path prepending, you can configure the AS Path for your prefix to influence routing. In dit voorbeeld kunt u het AS-pad voor 172.2.0.0/31 in US - oost verlengen zodat het ExpressRoute-circuit in US - west de voorkeur krijgt voor verkeer dat is bestemd voor dit voorvoegsel (omdat ons netwerk 'denkt' dat het pad naar dit voorvoegsel korter is in het westen).In this example, you can lengthen the AS PATH for 172.2.0.0/31 in US East so that we will prefer the ExpressRoute circuit in US West for traffic destined for this prefix (as our network will think the path to this prefix is shorter in the west). En zo verlengt u ook het AS-pad voor 172.2.0.2/31 in US - west, zodat het ExpressRoute-circuit in US - oost de voorkeur krijgt.Similarly you can lengthen the AS PATH for 172.2.0.2/31 in US West so that we'll prefer the ExpressRoute circuit in US East. Routering is geoptimaliseerd voor beide kantoren.Routing is optimized for both offices. Als bij dit ontwerp één ExpressRoute-circuit wordt verbroken, kan Exchange Online u nog steeds bereiken via een ander ExpressRoute-circuit en uw WAN.With this design, if one ExpressRoute circuit is broken, Exchange Online can still reach you via another ExpressRoute circuit and your WAN.

Belangrijk

We verwijderen persoonlijke AS-nummers in het AS-pad voor voorvoegsels die binnenkomen op Microsoft-peering.We remove private AS numbers in the AS PATH for the prefixes received on Microsoft Peering. U moet openbare AS-nummers aan het AS-pad toevoegen om routering voor Microsoft-peering te beïnvloeden.You need to append public AS numbers in the AS PATH to influence routing for Microsoft Peering.

Oplossing ExpressRoute casus 2: Toevoeging van AS PATH gebruiken

Notitie

Hoewel de hier getoonde voorbeelden voor Microsoft- en openbare peerings zijn, ondersteunen we dezelfde mogelijkheden voor persoonlijke peering.While the examples given here are for Microsoft and Public peerings, we do support the same capabilities for the Private peering. De AS-padtoevoeging werkt ook binnen één ExpressRoute-circuit om de selectie van primaire en secundaire paden te beïnvloeden.Also, the AS Path prepending works within one single ExpressRoute circuit, to influence the selection of the primary and secondary paths.

Suboptimale routering tussen virtuele netwerkenSuboptimal routing between virtual networks

Met ExpressRoute kunt u VNet-communicatie (communicatie van Virtual Network naar Virtual Network) inschakelen door de VNets te koppelen aan een ExpressRoute-circuit.With ExpressRoute, you can enable Virtual Network to Virtual Network (which is also known as "VNet") communication by linking them to an ExpressRoute circuit. Wanneer u ze koppelt aan meerdere ExpressRoute-circuits, kan er suboptimale routering tussen de VNets optreden.When you link them to multiple ExpressRoute circuits, suboptimal routing can happen between the VNets. Een voorbeeld.Let's consider an example. U hebt twee ExpressRoute-circuits, één in US - west en één in US - oost.You have two ExpressRoute circuits, one in US West and one in US East. In elke regio hebt u twee VNets.In each region, you have two VNets. Uw webservers zijn geïmplementeerd in het ene VNet en de toepassingsservers in het andere.Your web servers are deployed in one VNet and application servers in the other. 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.For redundancy, you link the two VNets in each region to both the local ExpressRoute circuit and the remote ExpressRoute circuit. Zoals u hieronder kunt zien, lopen er vanuit elk VNet twee paden naar het andere VNet.As can be seen below, from each VNet there are two paths to the other VNet. De VNets weten niet welk ExpressRoute-circuit lokaal is en welk circuit extern.The VNets don't know which ExpressRoute circuit is local and which one is remote. Omdat er ECMP-routering (Equal-Cost-Multi-Path) plaatsvindt om het verkeer tussen VNets gelijk te verdelen, kan het daardoor gebeuren dat verkeer een langere weg aflegt en naar het externe ExpressRoute-circuit wordt omgeleid.Consequently as they do Equal-Cost-Multi-Path (ECMP) routing to load-balance inter-VNet traffic, some traffic flows will take the longer path and get routed at the remote ExpressRoute circuit.

Probleem ExpressRoute casus 3: Suboptimale routering tussen virtuele netwerken

Oplossing: meer gewicht toewijzen aan lokale verbindingSolution: assign a high weight to local connection

De oplossing is eenvoudig.The solution is simple. Omdat u weet waar de VNets en circuits zich bevinden, kunt u ons vertellen aan welk pad elke VNet de voorkeur moet geven.Since you know where the VNets and the circuits are, you can tell us which path each VNet should prefer. Voor dit voorbeeld wijst u aan de lokale verbinding een hoger gewicht toe dan aan de externe verbinding (klik hier voor een configuratievoorbeeld).Specifically for this example, you assign a higher weight to the local connection than to the remote connection (see the configuration example here). Wanneer een VNet op meerdere verbindingen het voorvoegsel van het andere VNet ontvangt, krijgt de verbinding met het hoogste gewicht de voorkeur om verkeer te verzenden dat voor dat voorvoegsel is bestemd.When a VNet receives the prefix of the other VNet on multiple connections it will prefer the connection with the highest weight to send traffic destined for that prefix.

Oplossing ExpressRoute casus 3: Meer gewicht toewijzen aan lokale verbinding

Notitie

Als u meerdere ExpressRoute-circuits hebt, kunt u de routering vanuit VNet naar uw on-premises netwerk ook beïnvloeden door het gewicht van een verbinding te configureren in plaats van AS PATH aan het begin toe te voegen, een techniek die in het tweede scenario hierboven is beschreven.You can also influence routing from VNet to your on-premises network, if you have multiple ExpressRoute circuits, by configuring the weight of a connection instead of applying AS PATH prepending, a technique described in the second scenario above. 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.For each prefix, we will always look at the connection weight before the AS Path length when deciding how to send traffic.