SDWAN-integrering med azure hub-and-spoke-nätverkstopologier

Den här artikeln är avsedd för nätverksarkitekter som vill utforma programvarudefinierade SD-WAN (Wide Area Networks) för att ansluta lokala anläggningar till varandra och med Azure. Den beskriver en arkitektur som gör att Azure-kunder kan använda sina befintliga investeringar i plattformen genom att skapa effektiva, globala SD-WAN-överlägg ovanpå Microsofts stamnät.

Tillämpliga scenarier

Rekommendationerna i den här artikeln är leverantörsoberoende och tillämpliga på alla SD-WAN-tekniker som inte kommer från Microsoft och som uppfyller två grundläggande förutsättningar:

• Beroende av tunnelprotokoll som använder TCP (Transmission Control Protocol) eller Udp (User Datagram Protocol) som den underliggande transporten, till exempel att vara IPsec ESP i tunnelläge med NAT-Traversal.
• BGP v4-stöd (Border Gateway Protocol) för routningsutbyte med externa entiteter. Inga antaganden görs om routningsprotokollet som används av SD-WAN-enheter som inte kommer från Microsoft för att utbyta routningsinformation mellan varandra.

Kunder som följer dessa rekommendationer kan använda valfri SD-WAN-teknik för att uppnå följande mål:

• Integrera SD-WAN-produkter i ett befintligt Azure-hubb- och ekernätverk genom att automatisera routningsutbytet mellan Azure Virtual Network- och SD-WAN-enheter.
• Optimera anslutningen (både till Azure och lokala datacenter) för grenar med lokala internetbrytningar. Räckvidden för Microsofts stamnät, i kombination med dess policy för kapacitet, återhämtning och "kall potatis" tyder på att den kan användas som ett högpresterande underlägg för globala SD-WAN.
• Använd Microsofts stamnät för all Azure-till-Azure-trafik (mellan regioner och mellan geografiska områden).
• Använd befintliga MPLS-nätverk (Multi-Protocol-Label-Switching) som underlägg med höga prestanda. Det kan också användas för att ersätta ett befintligt MPLS-nätverk i en stegvis metod som minimerar effekten på verksamheten.

Följande avsnitt förutsätter att läsaren är bekant med grunderna i detSD-WAN paradigmet och arkitekturen i Microsofts stamnät. Microsofts stamnät kopplar samman Azure-regioner med varandra och med det offentliga Internet.

Arkitektur

Organisationer med global närvaro och ett Azure-fotavtryck i flera regioner använder vanligtvis en kombination av anslutningstjänster för att implementera sina företagsnätverk och för att ansluta till Microsofts stamnät:

• Dedikerade anslutningstjänster, till exempel MPLS Internet-Protocol-Virtual-Private-Networks (IPVPN), kan användas på de största platserna, till exempel datacenter eller huvudkontor.
• Stora platser kan omfatta dedikerad anslutning till Microsofts stamnät via ExpressRoute-kretsar med hjälp av en av anslutningsmodellerna som stöds. Mer specifikt kan en plats använda dedikerade punkt-till-punkt-kretsar för att ansluta till närmaste ExpressRoute-peeringplats. Eller så kan den använda sin MPLS IPVPN för att få åtkomst till ExpressRoute-kretsar som tillhandahålls av MPLS-operatören.
• Avdelningskontor som bara har internetanslutning kan använda IPsec VPN för att ansluta till närmaste lokala datacenter och använda det datacentrets ExpressRoute-anslutning för att få åtkomst till Azure-resurser. Eller så kan de använda VPN:er för IPsec för att ansluta direkt till Azure Hub- och spoke-nätverk.

SD-WAN-projekt kan ha olika omfång när det gäller vilka traditionella nätverkstjänster de tänker ersätta. Vissa organisationer kanske vill hålla sig till dedikerade länkar eller MPLS för stora anläggningar och distribuera en SD-WAN endast för att ersätta äldre Internetbaserade VPN:er för IPsec på små platser. Andra organisationer kanske vill utöka sitt SD-WAN till MPLS-anslutna platser och använda det befintliga MPLS-nätverket som ett underlägg med höga prestanda. Slutligen kanske vissa organisationer vill stänga sina MPLS IPVPN:er. eller någon dedikerad anslutningstjänst för att omfamna SD-WAN-paradigmet. På så sätt kan de skapa hela sitt företagsnätverk som ett logiskt överlägg ovanpå offentliga eller delade underlägg (det offentliga Internet och Microsofts stamnät).

Arkitekturen som beskrivs i den här artikeln stöder alla omfång som anges tidigare och baseras på följande principer:

• SD-WAN-enheter distribueras som virtuella nätverksinstallationer (NVA) i varje Azure-regions nav- och ekernätverk och konfigureras som SD-WAN-hubbar som avslutar tunnlar från lokala platser.
• SD-WAN-enheter i Azure är konfigurerade för att upprätta tunnlar med varandra, vilket skapar ett helt nätbaserat nav-till-nav-överlägg som effektivt kan transportera trafik mellan Azure-regioner och vidarebefordra trafik mellan geografiskt avlägsna lokala platser, ovanpå Microsofts stamnät.
• SD-WAN-enheter distribueras på alla lokala platser som omfattas av SD-WAN-lösningen och konfigureras för att upprätta tunnlar till SD-WAN NVA i närmaste Azure-regioner. Olika platser kan använda olika transporttjänster som ett underlägg för tunnlarna, till exempel offentligt Internet, ExpressRoute-anslutning och så vidare.
• Trafik från en plats till ett mål, oavsett om det är i Azure eller på en annan lokal plats, dirigeras till SD-WAN NVA:erna i den närmaste Azure-regionen. Sedan dirigeras den genom hubb-till-hubb-överlägget.

SD-WAN-produkter kan använda patentskyddade protokoll och funktioner för att upptäcka att direkttunnlar mellan två platser kan ge bättre prestanda än att vidarebefordra trafik via SD-WAN NVA:er i Azure när de väl har upprättats dynamiskt.

Den övergripande arkitekturen för ett globalt SD-WAN som använder Microsofts stamnät, det offentliga Internet och dedikerade ER-anslutningar som underlägg visas i följande bild.

Bild 1: Arkitektur på hög nivå för en global SD-WAN som använder Microsofts stamnät, det offentliga Internet och dedikerade ER-anslutningar som underlägg. Den svarta streckade linjen visar hur trafik mellan två lokala platser kan dirigeras via SD-WAN NVA:er som distribueras i Azure-regioner geografiskt nära platserna. Microsofts stamnät kan på grund av sin räckvidd, kapacitet och "kallpotatis"-routningsprincip leda till betydligt bättre/förutsägbara prestanda än det offentliga Internet, särskilt för långdistansanslutningar.

SD-WAN-produkter i Azure hub-and-spoke-nätverk

Det här avsnittet innehåller rekommendationer för att distribuera icke-Microsoft SD-WAN CPE-enheter som NVA:er i ett befintligt hubb- och ekernätverk i Azure.

SD-WAN NVA i det virtuella hubbnätverket

Hub and Spoke är den topologi som Microsoft rekommenderar för att skapa skalbara nätverk i en Azure-region med hjälp av kundhanterade virtuella nätverk. Det virtuella hubbnätverket är värd för delade komponenter som icke-Microsoft NVA:er och interna tjänster som tillhandahåller nätverksfunktioner, till exempel brandvägg, belastningsutjämning och anslutning till lokala platser via plats-2-plats-VPN eller ExpressRoute. Det virtuella hubbnätverket är den naturliga platsen för SD-WAN NVA:er, som i slutändan är icke-Microsoft-gatewayer som ger åtkomst till fjärrnätverk.

SD-WAN NVA:er bör distribueras i virtuella hubbnätverk enligt följande:

• En enda nätverksgränssnittsstyrenhet (NIC) används för all SD-WAN-trafik. Andra nätverkskort, till exempel ett nätverkskort för hantering, kan läggas till för att uppfylla säkerhets- och efterlevnadskrav eller för att följa leverantörsriktlinjerna för Azure-distributioner.
• Det nätverkskort som används för SD-WAN-trafik måste vara kopplat till ett dedikerat undernät. Storleken på undernätet måste definieras baserat på antalet SD-WAN NVA:er som distribuerats för att uppfylla kraven på hög tillgänglighet (HA) och skalning eller dataflöde, som beskrivs senare i den här artikeln.
• Nätverkssäkerhetsgrupper (NSG:er) måste vara kopplade till SD-WAN-trafikkortet, antingen direkt eller på undernätsnivå. Den här associationen tillåter anslutningar från lokala fjärrplatser via de TCP/UDP-portar som används av SD-WAN-lösningen.
• IP-vidarebefordran måste vara aktiverat på det nätverkskort som används för SD-WAN-trafik.

Azure Route Server i det virtuella hubbnätverket

Azure Route Server automatiserar routningsutbytet mellan SD-WAN NVA:er och SDN-stacken (Azure Software Defined Networking). Route Server stöder BGP som ett dynamiskt routningsprotokoll. Genom att upprätta BGP-adjacencies mellan Route Server och SD-WAN NVA:erna:

• Vägar för alla lokala platser som är anslutna till SD-WAN matas in i det virtuella nätverkets routningstabeller och lärs av alla virtuella Azure-datorer.
• Vägar för alla IP-prefix som ingår i adressutrymmet för virtuella nätverk sprids till alla SD-WAN-anslutna platser.

Routningsservern bör konfigureras på följande sätt.

• Den måste distribueras i ett dedikerat undernät i det virtuella hubbnätverket enligt Skapa och konfigurera Routningsserver med hjälp av Azure-portalen.
• För att aktivera automatiserat vägutbyte för alla virtuella ekernätverk måste peering för virtuella nätverk konfigureras så att de virtuella ekernätverken kan använda det virtuella hubbnätverkets gateway och routningsserver. Information finns i vanliga frågor och svar om Azure Route Server.
• Eftersom Routningsservern och SD-WAN NVA:erna är kopplade till olika undernät måste BGP-sessioner mellan Route Server och SD-WAN NVA konfigureras med stöd för eBGP multihop. Valfritt antal hopp mellan 2 och det högsta antal som stöds av SD-WAN NVA kan anges. Information om hur du konfigurerar BGP-adjacencies för Route Server finns i Skapa och konfigurera Routningsserver med hjälp av Azure-portalen.
• Två /32 statiska vägar måste konfigureras på SD-WAN NVA för de BGP-slutpunkter som exponeras av routningsservern. Den här konfigurationen säkerställer att NVA:s routningstabell alltid innehåller vägar för dess BGP-peer-datorer (inte direkt anslutna).

Routningsservern finns inte i datasökvägen. Det är en kontrollplansentitet. Den sprider vägar mellan SD-WAN NVA och SDN-stacken för det virtuella nätverket, men den faktiska trafikvidarebefordran mellan SD-WAN NVA och de virtuella datorerna i det virtuella nätverket görs av Azure SDN-stacken, enligt följande bild. För att få det här routningsbeteendet matar Route Server in alla vägar som den lär sig från SD-WAN NVA:erna med nästa hopp inställt på NVA:ns egen adress.

Routningsservern stöder inte IPv6 från och med nu. Den här arkitekturen är endast för IPv4.

Bild 2. Route Server stöder routningsspridning mellan SD-WAN CPE och SDN-stacken för virtuella nätverk, men vidarebefordrar inte trafik mellan SD-WAN CPE och de virtuella datorerna i det virtuella nätverket.

Hög tillgänglighet för SD-WAN NVA med Route Server

Routningsservern har inbyggd HA. Två beräkningsnoder backar en enda instans av Route Server. De distribueras i olika tillgänglighetszoner, för de regioner som har stöd för tillgänglighetszoner eller i samma tillgänglighetsuppsättning. De exponerar två BGP-slutpunkter. HA för SD-WAN NVA uppnås genom att distribuera flera instanser i olika tillgänglighetszoner, för regioner som stöder dem eller i samma tillgänglighetsuppsättning. Varje SD-WAN NVA upprättar två BGP-sessioner med båda slutpunkterna exponerade av Route Server.

Arkitekturen som beskrivs i den här artikeln förlitar sig inte på Azure Load Balancers. Mer specifikt:

• Inga offentliga lastbalanserare exponerar SD-WAN-tunnelslutpunkter. Varje SD-WAN NVA exponerar sin egen tunnelslutpunkt. Fjärranslutna peer-datorer upprättar flera tunnlar, en för varje SD-WAN NVA i Azure.

• Inga interna lastbalanserare distribuerar trafiken från virtuella Azure-datorer till SD-WAN NVA:erna. Routningsservern och Azure SDN-stacken stöder ECMP-routning (Equal-Cost Multipath). Om flera NVA:er konfigurerar BGP-adjacencies med Route Server och meddelar vägar för samma mål (som i fjärrnätverk och platser som är anslutna till SD-WAN) med samma inställningsgrad, routningsserver:

  • Matar in flera vägar för dessa mål i det virtuella nätverkets routningstabell.
  • Anger att varje väg ska använda en annan NVA som nästa hopp.

SDN-stacken distribuerar sedan trafik till dessa mål över alla tillgängliga nästa hopp.

Den resulterande HA-arkitekturen visas i följande bild:

Bild 3. Route Server stöder Equal-Cost MULTIPATH-routning (ECMP). Azure Load Balancers behövs inte när flera SD-WAN NVA:er används i tillgänglighets- och/eller skalbarhetssyfte.

N-aktiv kontra aktiv stand-by hög tillgänglighet

När du använder flera SD-WAN NVA:er och peerkopplar dem med Routningsservern, kör BGP redundansväxlingen. Om en SD-WAN NVA går offline stoppas annonseringsvägar till Route Server. De vägar som har lärts från den misslyckade enheten dras sedan tillbaka från det virtuella nätverkets routningstabell. Så om en SD-WAN NVA inte längre tillhandahåller anslutning till fjärranslutna SD-WAN-platser på grund av ett fel, i själva enheten eller i underlägget, visas den inte längre som ett möjligt nästa hopp mot fjärrplatserna i det virtuella nätverkets routningstabell. All trafik går till de återstående felfria enheterna. Mer information om routningsspridning mellan SD-WAN NVA:er och routningsserver finns i Vägar som annonseras av en BGP-peer till routningsserver.

Bild 4. BGP-driven redundansväxling. Om SD-WAN NVA #0 går offline stängs dess BGP-sessioner med Routningsservern. SD-WAN NVA #0 tas bort från det virtuella nätverkets routningstabell som ett möjligt nästa hopp för trafik som går från Azure till en lokal plats.

BGP-driven redundans och ECMP-routning aktiverar naturligt N-aktiv HA-arkitekturer med N-enheter som bearbetar trafik samtidigt. Men du kan också använda BGP för att implementera aktiva och passiva HA-arkitekturer: konfigurera den passiva enheten så att den meddelar Routningsservern med lägre prioritet än dess aktiva peer. Routningsservern tar bort de vägar som tas emot från den passiva enheten om den tar emot alla vägar för samma mål med högre prioritet från den aktiva enheten. Och det fyller bara de senare vägarna i det virtuella nätverkets routningstabell.

Om den aktiva enheten misslyckas eller drar tillbaka några av sina vägar, routningsservern:

• Väljer motsvarande vägar som meddelats av den passiva enheten.
• Fyller i vägarna i det virtuella nätverkets routningstabell.

De enda BGP-attribut som SD-WAN NVA:er kan använda för att uttrycka en viss prioritet för de vägar som de meddelar till Route Server är AS-sökväg.

Vi rekommenderar N-active HA-arkitekturer eftersom de möjliggör optimal resursanvändning (det finns inga stand-by SD-WAN NVA:er) och horisontell skalbarhet. För att öka dataflödet kan flera NVA:er köras parallellt, upp till det maximala antalet BGP-peer-datorer som stöds av Route Server. Mer information finns i BGP-peer-datorer. Men N-active HA-modellen kräver att SD-WAN NVA:erna fungerar som tillståndslösa layer 3-routrar. När det finns flera tunnlar till en plats kan TCP-anslutningar dirigeras asymmetriskt. Det vill: ORIGINAL - och REPLY-flödena för samma TCP-anslutning kan dirigeras genom olika tunnlar och olika NVA:er. Följande bild visar ett exempel på en asymmetriskt dirigerad TCP-anslutning. Sådana routningsasymmetrier är möjliga för TCP-anslutningar som initieras i det virtuella nätverket eller på den lokala platsen.

Bild 5. Asymmetrisk routning i aktiva/aktiva HA-arkitekturer. SD-WAN NVA #0 och SD-WAN NVA #1 meddelar samma väg för mål 192.168.1.0/24 (fjärransluten SD-WAN plats) med samma längd på AS-sökvägen till routningsservern. Det ursprungliga flödet (från SD-WAN fjärrplats till Azure, röd sökväg) dirigeras via tunneln som avslutas på Azure-sidan av SD-WAN NVA #1. Den lokala SD-WAN CPE väljer den här tunneln. Azure SDN-stacken dirigerar REPLY-flödet (från Azure till fjärransluten SD-WAN plats, grön sökväg) till SD-WAN NVA #0, vilket är en av de möjliga nästa hoppen för 192.168.1.0/24, enligt det virtuella nätverkets routningstabell. Det går inte att garantera att nästa hopp som väljs av Azure SDN-stacken alltid är samma SD-WAN CPE som tog emot originalflödet.

Aktiva och passiva HA-arkitekturer bör endast beaktas när SD-WAN NVA:er i Azure utför andra nätverksfunktioner som kräver routningssymmetri, till exempel tillståndskänslig brandvägg. Vi rekommenderar inte den här metoden på grund av dess konsekvenser för skalbarheten. Om du kör fler nätverksfunktioner på SD-WAN NVA ökar resursförbrukningen. Samtidigt tillåter den aktiva och passiva HA-arkitekturen att ha en enda NVA-bearbetningstrafik när som helst. Det vill: hela SD-WAN-lagret kan bara skalas upp till den maximala Azure VM-storlek som den stöder, inte skalas ut. Kör tillståndskänsliga nätverksfunktioner som kräver routningssymmetri i separata NVA-kluster som förlitar sig på Standard Load Balancer för n-aktiv HA.

Överväganden för ExpressRoute-anslutning

Arkitekturen som beskrivs i den här artikeln låter kunderna fullt ut anamma SD-WAN-paradigmet och bygga sitt företagsnätverk som ett logiskt överlägg ovanpå det offentliga Internet och Microsofts stamnät. Det stöder också användning av dedikerade Expressroute-kretsar för att hantera specifika scenarier, som beskrivs senare.

Scenario nr 1: ExpressRoute och SD-WAN samexistens

SD-WAN-lösningar kan samexistera med ExpressRoute-anslutning när SD-WAN-enheter endast distribueras på en delmängd av platser. Vissa organisationer kan till exempel distribuera SD-WAN lösningar som ersättning för traditionella VPN:er för IPsec på platser med endast Internetanslutning. Sedan använder de MPLS-tjänster och ExpressRoute-kretsar för stora platser och datacenter, enligt följande bild.

Bild 6. SD-WAN lösningar kan samexistera med ExpressRoute-anslutning när SD-WAN CPE-enheter endast distribueras på en delmängd platser.

Det här samexistensscenariot kräver att SD-WAN NVA:er som distribueras i Azure kan dirigera trafik mellan platser som är anslutna till SD-WAN och platser som är anslutna till ExpressRoute-kretsar. Routningsservern kan konfigureras för att sprida vägar mellan virtuella ExpressRoute-nätverksgatewayer och SD-WAN NVA:er i Azure genom att aktivera funktionen, enligt beskrivningen AllowBranchToBranchhär. Routningsspridning mellan den virtuella ExpressRoute-nätverksgatewayen och SD-WAN NVA:erna sker via BGP. Route Server upprättar BGP-sessioner med båda och sprids till varje peer som vägarna har lärt sig från den andra. Plattformen hanterar BGP-sessionerna mellan Route Server och den virtuella ExpressRoute-nätverksgatewayen. Användarna behöver inte konfigurera dem explicit, utan bara för att aktivera AllowBranchToBranch flaggan när de distribuerar Routningsservern.

Bild 7. Routningsspridning mellan den virtuella ExpressRoute-nätverksgatewayen och SD-WAN NVA:er sker via BGP. Route Server upprättar BGP-sessioner med båda och sprider vägar i båda riktningarna när de konfigureras med "AllowBranchToBranch=TRUE". Routningsservern fungerar som en vägreflektor, dvs. den är inte en del av datasökvägen.

Det här samexistensscenariot för SD-WAN och ExpressRoute möjliggör migreringar från MPLS-nätverk till SD-WAN. Den erbjuder en väg mellan äldre MPLS-webbplatser och nyligen migrerade SD-WAN-platser, vilket eliminerar behovet av att dirigera trafik genom lokala datacenter. Det här mönstret kan användas inte bara under migreringar utan även i scenarier som uppstår vid företagssammanslagningar och förvärv, vilket ger en sömlös sammankoppling av olika nätverk.

Scenario nr 2: Expressroute som ett SD-WAN-underlägg

Om dina lokala platser har ExpressRoute-anslutning kan du konfigurera SD-WAN-enheter för att konfigurera tunnlar till SD-WAN-hubbens NVA:er som körs i Azure ovanpå ExpressRoute-kretsen eller -kretsarna. ExpressRoute-anslutning kan göras via punkt-till-punkt-kretsar eller ett MPLS-nätverk. Du kan använda både privat ExpressRoute-peering och Microsoft-peering.

Privat peering

När du använder den privata ExpressRoute-peeringen som underlägg upprättar alla lokala SD-WAN-platser tunnlar till SD-WAN-hubbens NVA:er i Azure. Ingen routningsspridning mellan SD-WAN NVA:erna och den virtuella ExpressRoute-nätverksgatewayen behövs i det här scenariot (det vill säga routningsservern måste konfigureras med flaggan "AllowBranchToBranch" inställd på false).

Den här metoden kräver korrekt BGP-konfiguration på de routrar på kund- eller providersidan som avslutar ExpressRoute-anslutningen. Faktum är att Microsoft Enterprise Edge-routrar (MSEE) meddelar alla vägar för de virtuella nätverk som är anslutna till kretsen (antingen direkt eller via peering för virtuella nätverk). Men för att vidarebefordra trafik till virtuella nätverk via en SD-WAN-tunnel bör den lokala platsen lära sig dessa vägar från SD-WAN-enheten – inte ER-kretsen.

Därför måste de routrar på kundsidan eller providersidan som avslutar ExpressRoute-anslutningen filtrera bort de vägar som tas emot från Azure. De enda vägar som konfigureras i underlägget ska vara de som gör det möjligt för de lokala SD-WAN-enheterna att nå SD-WAN-hubbens NVA:er i Azure. Kunder som vill använda den privata ExpressRoute-peeringen som SD-WAN-underlägg bör kontrollera att de kan konfigurera sina routningsenheter i enlighet med detta. Detta är särskilt relevant för kunder som inte har direkt kontroll över sina gränsenheter för ExpressRoute. Ett exempel är när ExpressRoute-kretsen tillhandahålls av en MPLS-operatör ovanpå en IPVPN-tjänst.

Bild 8. ExpressRoute privat peering som ett SD-WAN underlägg. I det här scenariot tar kund- och providersidans routrar emot vägarna för det virtuella nätverk som avslutar ExpressRoute-anslutningen, i BGP-sessioner för privat peering för ER och SD-WAN CPE. Endast SD-WAN CPE ska sprida Azure-vägarna till webbplatsens LAN.

Microsoft-peering

Du kan också använda ExpressRoute Microsoft-peering som underlägg för SD-WAN-tunnlar. I det här scenariot exponerar SD-WAN-hubbens NVA:er i Azure endast offentliga tunnelslutpunkter, som används av både SD-WAN-PROCESSORer på internetanslutna platser, om några, och av SD-WAN-CPEs på Expressroute-anslutna platser. Även om ExpressRoute Microsoft-peering har mer komplexa förutsättningar än den privata peeringen rekommenderar vi att du använder det här alternativet som ett underlägg på grund av dessa två fördelar:

• Det kräver inte virtuella Expressroute-nätverksgatewayer i det virtuella hubbnätverket. Det tar bort komplexitet, minskar kostnaderna och gör att SD-WAN lösning kan skalas utanför bandbreddsgränserna för själva gatewayen när du inte använder ExpressRoute FastPath.

• Det ger en ren separation mellan överläggs- och underläggsvägar. MSEE:erna meddelar endast Microsoft-nätverkets offentliga prefix till kunden eller leverantörsgränsen. Du kan hantera dessa vägar i en separat VRF och endast sprida till ett DMZ-segment av webbplatsens LAN. SD-WAN-enheter sprider vägarna för kundens företagsnätverk i överlägget, inklusive vägar för virtuella nätverk. Kunder som överväger den här metoden bör kontrollera att de kan konfigurera sina routningsenheter i enlighet med detta eller begära rätt tjänst till sin MPLS-operatör.

MPLS-överväganden

Migrering från traditionella MPLS-företagsnätverk till modernare nätverksarkitekturer baserade på SD-WAN-paradigmet kräver en betydande ansträngning och mycket tid. Arkitekturen som beskrivs i den här artikeln möjliggör stegvisa SD-WAN-migreringar. Två typiska migreringsscenarier beskrivs senare.

Stegvis MPLS-inaktivering

Kunder som vill skapa en SD-WAN ovanpå det offentliga Internet och Microsofts stamnät, och helt inaktivera MPLS IPVPN eller andra dedikerade anslutningstjänster, kan använda ExpressRoute och SD-WAN samexistensscenario som beskrivs i föregående avsnitt under migreringen. Det gör det möjligt för SD-WAN-anslutna platser att nå webbplatser som fortfarande är anslutna till den äldre MPLS. Så snart en plats har migrerats till SD-WAN- och CPE-enheter distribueras kan dess MPLS-länk inaktiveras. Webbplatsen kan komma åt hela företagsnätverket via sina SD-WAN-tunnlar till närmaste Azure-regioner.

Bild 9. Scenariot "ExpressRoute och SD-WAN samexistens" möjliggör stegvis MPLS-inaktivering.

När alla platser migreras kan MPLS IPVPN inaktiveras, tillsammans med ExpressRoute-kretsarna som ansluter den till Microsofts stamnät. Virtuella ExpressRoute-nätverksgatewayer behövs inte längre och kan avetableras. SD-WAN-hubbens NVA:er i varje region blir den enda startpunkten i regionens nav- och ekernätverk.

MPLS-integrering

Organisationer som inte litar på offentliga och delade nätverk för att tillhandahålla önskad prestanda och tillförlitlighet kan besluta att använda ett befintligt MPLS-nätverk som ett underlägg i företagsklass. Två alternativ är:

• En delmängd av platser som datacenter eller stora avdelningskontor.
• En delmängd av anslutningar, vanligtvis svarstidskänslig eller verksamhetskritisk trafik.

Scenariot Expressroute som ett SD-WAN underlägg som beskrevs tidigare möjliggör SD-WAN- och MPLS-integrering. ExpressRoute Microsoft-peering bör föredras framför den privata peeringen av de skäl som diskuterats tidigare. När Microsoft-peering används blir ÄVEN MPLS-nätverket och det offentliga Internet funktionellt likvärdiga underlägg. De ger åtkomst till alla SD-WAN-tunnelslutpunkter som exponeras av SD-WAN Hub NVA:er i Azure. En SD-WAN CPE som distribueras på en plats med både Internet- och MPLS-anslutning kan upprätta flera tunnlar till SD-WAN-hubbarna i Azure på båda underläggen. De kan sedan dirigera olika anslutningar genom olika tunnlar, baserat på principer på programnivå som hanteras av SD-WAN-kontrollplanet.

Bild 10. Scenariot "ExpressRoute som ett SD-WAN underlägg" möjliggör SD-WAN- och MPLS-integrering.

Routningsinställning för routning av routning

I båda MPLS-scenarierna som beskrivs i de två föregående avsnitten kan vissa grenplatser anslutas både till MPLS IPVPN och till SD-WAN. Därför kan routningsserverinstanserna som distribueras i de virtuella hubbnätverken lära sig samma vägar från ExpressRoute-gatewayer och SD-WAN NVA:er. Routningsinställningar för routning av routning för routning av routning gör det möjligt att styra vilken sökväg som ska föredras och skickas till de virtuella nätverkens routningstabeller. Routningsinställningen är användbar när AS Path-prepending inte kan användas. Ett exempel är MPLS IPVPN-tjänster som inte stöder anpassade BGP-konfigurationer på de PEs som avslutar ExpressRoute-anslutningar.

Vägserverbegränsningar och designöverväganden

Route Server är hörnstenen i arkitekturen som beskrivs i den här artikeln. Den sprider vägar mellan SD-WAN NVA:er som distribueras i virtuella nätverk och den underliggande Azure SDN-stacken. Det ger en BGP-baserad metod för att köra flera SD-WAN NVA:er för hög tillgänglighet och horisontell skalbarhet. När du utformar stora SD-WANs baserat på den här arkitekturen måste skalbarhetsgränserna för Route Server beaktas.

Följande avsnitt innehåller vägledning om maximal skalbarhet och hur du hanterar varje gräns.

Vägar som annonseras av en BGP-peer till routningsserver

Routningsservern definierar inte någon explicit gräns för antalet vägar som kan annonseras till virtuella ExpressRoute-nätverksgatewayer när AllowBranchToBranch flaggan anges. ExpressRoute-gatewayer sprider dock vidare de vägar som de lär sig från Route Server till de ExpressRoute-kretsar som de är anslutna till.

Det finns en gräns för antalet vägar som ExpressRoute-gatewayer kan annonsera till ExpressRoute-kretsar över den privata peeringen, som dokumenteras vid Azure-prenumerations- och tjänstgränser, kvoter och begränsningar. När du utformar SD-WAN-lösningar baserat på vägledningen i den här artikeln är det viktigt att se till att SD-WAN-vägar inte leder till att den här gränsen uppnås. Vid träff avbryts BGP-sessionerna mellan ExpressRoute-gatewayer och ExpressRoute-kretsar och anslutningen mellan virtuella nätverk och fjärrnätverk som är anslutna via ExpressRoute går förlorad.

Det totala antalet vägar som annonseras till kretsar av ExpressRoute Gateways är summan av antalet vägar som lärts från Route Server och antalet prefix som utgör Azure Hub- och spoke-nätverkets adressutrymme. För att undvika avbrott på grund av borttagna BGP-sessioner rekommenderar vi att du implementerar följande åtgärder:

• Använd inbyggda SD-WAN-enheters funktioner för att begränsa antalet vägar som aviserats till Route Server, om funktionen är tillgänglig.
• Använd Azure Monitor-aviseringar för att proaktivt identifiera toppar i antalet vägar som meddelas av ExpressRoute-gatewayer. Måttet som ska övervakas heter Antal vägar som annonseras till peer, enligt beskrivningen i ExpressRoute-övervakning.

BGP-peer-datorer

Route Server kan upprätta BGP-sessioner med upp till ett maximalt antal BGP-peer-datorer. Den här gränsen avgör det maximala antalet SD-WAN NVA:er som kan upprätta BGP-adjacencies med Route Server, och därmed det maximala aggregerade dataflödet som kan stödjas i alla SD-WAN-tunnlar. Endast stora SD-WAN:er förväntas nå den här gränsen. Det finns inga lösningar för att övervinna det, förutom att skapa flera nav- och ekernätverk, var och en med sina egna gatewayer och routningsservrar.

Deltagande virtuella datorer

Virtuella nätverksgatewayer och routningsserver konfigurerar de vägar som de lär sig från sina fjärranslutna peer-datorer för alla virtuella datorer i sitt eget virtuella nätverk och i direkt peer-kopplade virtuella nätverk. För att skydda Route Server från överdriven resursförbrukning på grund av routningsuppdateringar till virtuella datorer definierar Azure en gräns för antalet virtuella datorer som kan finnas i ett enda hubb- och ekernätverk. Det finns inga lösningar för att övervinna den här gränsen, förutom att skapa flera hubb- och ekernätverk, var och en med sina egna gatewayer och routningsservrar, i samma region.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Federico Guerrini - Sverige | Senior molnlösningsarkitekt
• Khush Kaviraj | Molnlösningsarkitekt

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Microsoft Well-Architected ramverk

Relaterade resurser

• Ansluta ett lokalt nätverk till Azure med ExpressRoute
• Distribuera NVA:er med hög tillgänglighet