Dit artikel is bedoeld voor netwerkarchitecten die Software-defined Wide Area Networks (SD-WAN's) willen ontwerpen om on-premises faciliteiten met elkaar en met Azure te verbinden. Het beschrijft een architectuur waarmee Azure-klanten hun bestaande investeringen in het platform kunnen gebruiken door efficiënte, wereldwijde SD-WAN-overlays te bouwen boven op de Microsoft-backbone.
Toepasselijke scenario's
De aanbevelingen in dit artikel zijn leverancierneutraal en van toepassing op alle niet-Microsoft SD-WAN-technologie die voldoet aan twee basisvereisten:
- Vertrouwen op tunnelingprotocollen die gebruikmaken van Transmission Control Protocol (TCP) of User Datagram Protocol (UDP) als het onderliggende transport, zoals ipsec-esp in de tunnelmodus met NAT-Traversal.
- Border Gateway Protocol (BGP) v4-ondersteuning voor routeuitwisseling met externe entiteiten. Er worden geen veronderstellingen gedaan op het routeringsprotocol dat door de niet-Microsoft SD-WAN-apparaten wordt gebruikt om routeringsinformatie tussen elkaar uit te wisselen.
Klanten die aan deze aanbevelingen voldoen, kunnen hun SD-WAN-technologie van keuze gebruiken om de volgende doelstellingen te bereiken:
- Integreer SD-WAN-producten in een bestaand Azure-hub- en spoke-netwerk door de routering tussen Azure Virtual Network- en SD-WAN-apparaten te automatiseren.
- Optimaliseer de connectiviteit (zowel naar Azure- als on-premises datacenters) voor vertakkingen met lokale internetonderbrekingen. Het bereik van de Microsoft-backbone, gecombineerd met de capaciteit, tolerantie en 'koude aardappel'-routeringsbeleid, stelt voor dat het kan worden gebruikt als een high-performance underlay voor globale SD-WAN's.
- Gebruik de Microsoft-backbone voor al het Azure-naar-Azure-verkeer (tussen regio's en geografische regio's).
- Gebruik bestaande MPLS-netwerken (Multi-Protocol-Label-Switching) als high-performance underlays. Het kan ook worden gebruikt om een bestaand MPLS-netwerk te vervangen in een gefaseerde benadering waarmee het effect op het bedrijf wordt geminimaliseerd.
In de volgende secties wordt ervan uitgegaan dat de lezer bekend is met de basisprincipes van het SD-WAN-paradigma en met de architectuur van de Microsoft-backbone. De Microsoft-backbone verbindt Azure-regio's met elkaar en met het openbare internet.
Architectuur
Organisaties met wereldwijde aanwezigheid en een Azure-footprint met meerdere regio's gebruiken doorgaans een combinatie van connectiviteitsservices om hun bedrijfsnetwerken te implementeren en verbinding te maken met de Microsoft-backbone:
- Toegewezen connectiviteitsservices, zoals MPLS Internet-Protocol-Virtual-Private-Networks (IPVPN's), kunnen worden gebruikt op de grootste sites, zoals datacenters of hoofdkantoor.
- Grote sites kunnen speciale connectiviteit met de Microsoft-backbone via ExpressRoute-circuits bevatten, met behulp van een van de ondersteunde connectiviteitsmodellen. Een site kan specifieke punt-naar-punt-circuits gebruiken om verbinding te maken met de dichtstbijzijnde ExpressRoute-peeringlocatie. Of het kan de MPLS IPVPN toepassen om toegang te krijgen tot ExpressRoute-circuits die worden geleverd door de MPLS-provider.
- Filialen met alleen internetverbinding kunnen IPSec VPN's gebruiken om verbinding te maken met het dichtstbijzijnde on-premises datacenter en de ExpressRoute-verbinding van dat datacenter te gebruiken voor toegang tot Azure-resources. Of ze kunnen IPSec VPN's gebruiken om rechtstreeks verbinding te maken met Azure-hub- en spoke-netwerken.
SD-WAN-projecten kunnen verschillende bereiken hebben in termen van welke traditionele netwerkservices ze willen vervangen. Sommige organisaties willen zich mogelijk houden aan speciale koppelingen of MPLS voor grote faciliteiten en een SD-WAN alleen implementeren om verouderde IPSec VPN's op internet te vervangen in kleine sites. Andere organisaties willen mogelijk hun SD-WAN uitbreiden naar sites die zijn verbonden met MPLS en het bestaande MPLS-netwerk gebruiken als een onderlay met hoge prestaties. Ten slotte willen sommige organisaties hun MPLS IPVPN's verwijderen. of een speciale connectiviteitsservice om het SD-WAN-paradigma te omarmen. Op deze manier kunnen ze hun hele bedrijfsnetwerk bouwen als een logische overlay boven op openbare of gedeelde onderlays (het openbare internet en de Microsoft-backbone).
De architectuur die in dit artikel wordt beschreven, ondersteunt alle eerder vermelde bereiken en is gebaseerd op de volgende principes:
- SD-WAN-apparaten worden geïmplementeerd als NVA's (Network Virtual Appliances) in het hub- en spoke-netwerk van elke Azure-regio en geconfigureerd als SD-WAN-hubs die tunnels van on-premises sites beëindigen.
- SD-WAN-apparaten in Azure zijn geconfigureerd om tunnels met elkaar tot stand te brengen, waardoor er een volledig meshed hub-naar-hub-overlay wordt gemaakt die efficiënt verkeer tussen Azure-regio's kan transporteren en verkeer tussen geografisch verre on-premises sites, boven op de Microsoft-backbone.
- SD-WAN-apparaten worden geïmplementeerd op alle on-premises sites die worden gedekt door de SD-WAN-oplossing en geconfigureerd voor het tot stand brengen van tunnels naar de SD-WAN NVA's in de dichtstbijzijnde Azure-regio's. Verschillende sites kunnen verschillende transportservices gebruiken als een onderlay voor de tunnels, zoals openbaar internet, ExpressRoute-connectiviteit, enzovoort.
- Verkeer van een site naar een bestemming, in Azure of in een andere on-premises site, wordt gerouteerd naar de SD-WAN NVA's in de dichtstbijzijnde Azure-regio. Vervolgens wordt de hub-naar-hub-overlay gerouteerd.
SD-WAN-producten kunnen eigen protocollen en functies gebruiken om te detecteren, zodra ze dynamisch tot stand zijn gebracht, directe tunnels tussen twee sites betere prestaties kunnen bieden dan het doorgeven van verkeer via SD-WAN NVA's in Azure.
De architectuur op hoog niveau van een globale SD-WAN die gebruikmaakt van de Microsoft-backbone, het openbare internet en toegewezen ER-verbindingen als onderlays, wordt weergegeven in de volgende afbeelding.
Afbeelding 1: Architectuur op hoog niveau van een globale SD-WAN die gebruikmaakt van de Microsoft-backbone, het openbare internet en toegewezen ER-verbindingen als onderlays. De zwarte stippellijn laat zien hoe verkeer tussen twee on-premises sites kan worden gerouteerd via SD-WAN NVA's die geografisch dicht bij de sites zijn geïmplementeerd in Azure-regio's. De Microsoft-backbone, vanwege het bereik, de capaciteit en het routeringsbeleid voor koude aardappels, kan leiden tot aanzienlijk betere/voorspelbare prestaties dan het openbare internet, met name voor langeafstandsverbindingen.
SD-WAN-producten in Azure Hub-and-Spoke-netwerken
Deze sectie bevat aanbevelingen voor het implementeren van niet-Microsoft SD-WAN CPE-apparaten als NVA's in een bestaand hub- en spoke-Azure-netwerk.
SD-WAN NVA's in het virtuele hubnetwerk
Hub and Spoke is de topologie die Microsoft aanbeveelt voor het bouwen van schaalbare netwerken in een Azure-regio met behulp van door de klant beheerde virtuele netwerken. Het virtuele hubnetwerk host gedeelde onderdelen, zoals niet-Microsoft NVA's en systeemeigen services die netwerkfuncties bieden, zoals firewalling, taakverdeling en connectiviteit met on-premises sites via site-2-site-VPN's of ExpressRoute. Het virtuele hubnetwerk is de natuurlijke locatie voor SD-WAN NVA's, die uiteindelijk niet-Microsoft-gateways zijn die toegang bieden tot externe netwerken.
SD-WAN NVA's moeten als volgt worden geïmplementeerd in virtuele hubnetwerken:
- Eén NIC (Network Interface Controller) wordt gebruikt voor alle SD-WAN-verkeer. Andere NIC's, zoals een beheer-NIC, kunnen worden toegevoegd om te voldoen aan de beveiligings- en nalevingsvereisten of om te voldoen aan de leveranciersrichtlijnen voor Azure-implementaties.
- De NIC die wordt gebruikt voor SD-WAN-verkeer, moet zijn gekoppeld aan een toegewezen subnet. De grootte van het subnet moet worden gedefinieerd op basis van het aantal SD-WAN NVA's dat is geïmplementeerd om te voldoen aan hoge beschikbaarheid en vereisten voor schaal of doorvoer, die verderop in dit artikel worden besproken.
- Netwerkbeveiligingsgroepen (NSG's) moeten worden gekoppeld aan de SD-WAN-verkeers-NIC, rechtstreeks of op subnetniveau. Deze koppeling staat verbindingen toe van externe on-premises sites via de TCP/UDP-poorten die worden gebruikt door de SD-WAN-oplossing.
- Doorsturen via IP moet zijn ingeschakeld op de NIC die wordt gebruikt voor SD-WAN-verkeer.
Azure Route Server in het virtuele hubnetwerk
Azure Route Server automatiseert de uitwisseling van routes tussen SD-WAN NVA's en de SdN-stack (Software Defined Networking). Route Server ondersteunt BGP als een dynamisch routeringsprotocol. Door BGP-aangrenzingen tot stand te brengen tussen de routeserver en de SD-WAN NVA('s):
- Routes voor alle on-premises sites die zijn verbonden met sd-WAN, worden opgenomen in de routetabellen van het virtuele netwerk en geleerd door alle Virtuele Azure-machines.
- Routes voor alle IP-voorvoegsels die zijn opgenomen in de adresruimte van virtuele netwerken, worden doorgegeven aan alle SD-WAN-verbonden sites.
De routeserver moet als volgt worden geconfigureerd.
- Het moet worden geïmplementeerd in een toegewezen subnet in het virtuele hubnetwerk volgens routeserver maken en configureren met behulp van Azure Portal.
- Als u geautomatiseerde routering voor alle virtuele spoke-netwerken wilt inschakelen, moet peering van virtuele netwerken voor virtuele spokes zo worden geconfigureerd dat de virtuele spoke-netwerken de gateway en routeserver van het virtuele hubnetwerk kunnen gebruiken. Details die beschikbaar zijn in de veelgestelde vragen over Azure Route Server.
- Aangezien routeserver en de SD-WAN NVA's zijn gekoppeld aan verschillende subnetten, moeten BGP-sessies tussen routeserver en SD-WAN NVA's worden geconfigureerd met eBGP multihop-ondersteuning. Een willekeurig aantal hops tussen 2 en het maximum dat wordt ondersteund door de SD-WAN NVA kan worden ingesteld. Meer informatie over het configureren van BGP-aangrenzingen voor routeserver zijn beschikbaar op Routeserver maken en configureren met behulp van De Azure-portal.
- Er moeten twee
/32statische routes worden geconfigureerd op de SD-WAN NVA voor de BGP-eindpunten die worden weergegeven door routeserver. Deze configuratie zorgt ervoor dat de routetabel van de NVA altijd routes bevat voor de BGP-peers met meerdere hops (niet rechtstreeks verbonden).
Routeserver bevindt zich niet in het gegevenspad. Het is een besturingsvlakentiteit. Routes worden doorgegeven tussen de SD-WAN NVA en de SDN-stack van het virtuele netwerk, maar het doorsturen van verkeer tussen de SD-WAN NVA en de virtuele machines in het virtuele netwerk wordt uitgevoerd door de Azure SDN-stack, zoals wordt weergegeven in de volgende afbeelding. Om dit routeringsgedrag te verkrijgen, injecteert Route Server alle routes die worden geleerd van de SD-WAN NVA's met de volgende hop ingesteld op het eigen adres van de NVA.
RouteServer biedt vanaf nu geen ondersteuning voor IPv6. Deze architectuur is alleen voor IPv4.
Afbeelding 2. RouteServer ondersteunt routedoorgifte tussen de SD-WAN CPE en de SDN-stack van het virtuele netwerk, maar stuurt geen verkeer door tussen de SD-WAN CPE en de virtuele machines in het virtuele netwerk.
Hoge beschikbaarheid voor SD-WAN NVA's met routeserver
Route Server heeft ingebouwde HA. Twee rekenknooppunten terug één exemplaar van Route Server. Ze worden geïmplementeerd in verschillende beschikbaarheidszones, voor de regio's met ondersteuning voor beschikbaarheidszones of in dezelfde beschikbaarheidsset. Ze maken twee BGP-eindpunten beschikbaar. Hoge beschikbaarheid voor de SD-WAN NVA's wordt bereikt door meerdere exemplaren in verschillende beschikbaarheidszones te implementeren voor regio's die deze ondersteunen of in dezelfde beschikbaarheidsset. Elke SD-WAN NVA brengt twee BGP-sessies tot stand met beide eindpunten die door routeserver worden weergegeven.
De architectuur die in dit artikel wordt beschreven, is niet afhankelijk van Azure Load Balancers. Specifieke opdrachten:
Er zijn geen openbare load balancers beschikbaar voor SD-WAN-tunneleindpunten. Elke SD-WAN NVA maakt een eigen tunneleindpunt beschikbaar. Externe peers maken meerdere tunnels tot stand, één voor elke SD-WAN NVA in Azure.
Er zijn geen interne load balancers die het verkeer distribueren dat afkomstig is van Azure-VM's naar de SD-WAN NVA's. Routeringsserver en de Azure SDN-stack bieden ondersteuning voor ECMP-routering (Equal Cost Multipath). Als meerdere NVA's BGP-aangrenzing met routeserver instellen en routes aankondigen voor dezelfde bestemmingen (zoals in, externe netwerken en sites die zijn verbonden met sd-WAN) met dezelfde mate van voorkeur, routeserver:
- Injecteert meerdere routes voor deze bestemmingen in de routetabel van het virtuele netwerk.
- Hiermee stelt u elke route in voor het gebruik van een andere NVA als de volgende hop.
De SDN-stack distribueert vervolgens verkeer naar die bestemmingen in alle beschikbare volgende hops.
De resulterende HA-architectuur wordt weergegeven in de volgende afbeelding:
Afbeelding 3. RouteServer biedt ondersteuning voor ECMP-routering (Equal-Cost Multipath). Azure Load Balancers zijn niet nodig wanneer meerdere SD-WAN NVA's worden gebruikt voor beschikbaarheids- en/of schaalbaarheidsdoeleinden.
N-actief versus actieve stand-by hoge beschikbaarheid
Wanneer u meerdere SD-WAN NVA's gebruikt en deze peert met routeserver, stuurt BGP de failover aan. Als een SD-WAN NVA offline gaat, stopt deze het adverteren van routes naar Route Server. De routes die zijn geleerd van het mislukte apparaat, worden vervolgens uit de routetabel van het virtuele netwerk ingetrokken. Dus als een SD-WAN NVA geen verbinding meer biedt met externe SD-WAN-sites vanwege een fout, in het apparaat zelf of in de underlay, wordt deze niet meer weergegeven als een mogelijke volgende hop naar de externe sites in de routetabel van het virtuele netwerk. Al het verkeer gaat naar de resterende apparaten die in orde zijn. Zie Routes die worden geadverteerd door een BGP-peer naar routeserver voor meer informatie over routedoorgifte tussen SD-WAN NVA's en Route Server.
Afbeelding 4. BGP-gestuurde failover. Als SD-WAN NVA #0 offline gaat, worden de BGP-sessies met routeserver gesloten. SD-WAN NVA #0 wordt verwijderd uit de routetabel van het virtuele netwerk als een mogelijke volgende hop voor verkeer van Azure naar een on-premises site.
BGP-gestuurde failover en ECMP-routering maken N-actieve HA-architecturen natuurlijk mogelijk met N-apparaten die gelijktijdig verkeer verwerken. U kunt echter ook BGP gebruiken om actieve en passieve HA-architecturen te implementeren: configureer het passieve apparaat om de routes met een lagere voorkeur aan te kondigen aan de routeserver dan de actieve peer. Routeserver negeert de routes die van het passieve apparaat worden ontvangen als deze routes ontvangt van het actieve apparaat eventuele routes voor dezelfde bestemmingen met een hogere mate van voorkeur. En het verpruimt alleen de laatste routes in de routetabel van het virtuele netwerk.
Als het actieve apparaat mislukt of een deel van de routes intrekt, wordt de routeserver gebruikt:
- Hiermee selecteert u de bijbehorende routes die worden aangekondigd door het passieve apparaat.
- Plumbs de routes in de routetabel van het virtuele netwerk.
De enige BGP-kenmerken die SD-WAN NVA's kunnen gebruiken om een zekere voorkeur uit te drukken voor de routes die ze aankondigen aan routeserver, is AS-pad.
We raden N-actieve HA-architecturen aan omdat ze optimaal resourcegebruik inschakelen (er zijn geen zelfstandige SD-WAN NVA's) en horizontale schaalbaarheid. Om de doorvoer te verhogen, kunnen meerdere NVA's parallel worden uitgevoerd, tot het maximum aantal BGP-peers dat wordt ondersteund door Route Server. Zie BGP-peers voor meer informatie. Maar het N-actieve HA-model vereist dat de SD-WAN NVA's fungeren als staatloze laag 3-routers. Wanneer er meerdere tunnels naar een site bestaan, kunnen TCP-verbindingen asymmetrisch worden gerouteerd. Dat wil gezegd, de ORIGINAL - en REPLY-stromen van dezelfde TCP-verbinding kunnen worden gerouteerd via verschillende tunnels en verschillende NVA's. In de volgende afbeelding ziet u een voorbeeld van een asymmetrisch gerouteerde TCP-verbinding. Dergelijke routerings-asymmetrieën zijn mogelijk voor TCP-verbindingen die zijn geïnitieerd op het virtuele netwerk of op de on-premises site.
Afbeelding 5. Asymmetrische routering in actieve/actieve HA-architecturen. SD-WAN NVA #0 en SD-WAN NVA #1 kondig dezelfde route aan voor bestemming 192.168.1.0/24 (externe SD-WAN-site) met dezelfde AS-padlengte naar routeserver. De OORSPRONKELIJKe stroom (van externe SD-WAN-site naar Azure, rood pad) wordt gerouteerd via de tunnel die is beëindigd, aan de Azure-zijde, door SD-WAN NVA #1. De on-premises SD-WAN CPE selecteert deze tunnel. De Azure SDN-stack routeert de REPLY-stroom (van Azure naar externe SD-WAN-site, groen pad) naar SD-WAN NVA #0, een van de mogelijke volgende hops voor 192.168.1.0/24, volgens de routetabel van het virtuele netwerk. Het is niet mogelijk om te garanderen dat de volgende hop die is gekozen door de Azure SDN-stack altijd dezelfde SD-WAN CPE is die de OORSPRONKELIJKe stroom heeft ontvangen.
Actieve en passieve HA-architecturen moeten alleen worden overwogen wanneer SD-WAN NVA's in Azure andere netwerkfuncties uitvoeren waarvoor routeringssymmetrie is vereist, zoals stateful firewalling. We raden deze aanpak niet aan vanwege de gevolgen voor schaalbaarheid. Het uitvoeren van meer netwerkfuncties op SD-WAN NVA's verhoogt het resourceverbruik. Tegelijkertijd maakt de actieve en passieve HA-architectuur het mogelijk om op elk moment één NVA-verwerkingsverkeer te hebben. Dat wil gezegd, de hele SD-WAN-laag kan alleen worden opgeschaald naar de maximale Azure-VM-grootte die wordt ondersteund, niet uitgeschaald. Voer stateful netwerkfuncties uit die routeringssymmetrie vereisen voor afzonderlijke NVA-clusters die afhankelijk zijn van Standard Load Balancer voor n-actieve ha.
Overwegingen voor ExpressRoute-connectiviteit
Met de architectuur die in dit artikel wordt beschreven, kunnen klanten het SD-WAN-paradigma volledig omarmen en hun bedrijfsnetwerk bouwen als een logische overlay boven op het openbare internet en de Microsoft-backbone. Het biedt ook ondersteuning voor het gebruik van toegewezen Expressroute-circuits om specifieke scenario's aan te pakken, die later worden beschreven.
Scenario 1: Co-existentie van ExpressRoute en SD-WAN
SD-WAN-oplossingen kunnen naast ExpressRoute-connectiviteit worden gebruikt wanneer SD-WAN-apparaten alleen in een subset van sites worden geïmplementeerd. Sommige organisaties kunnen bijvoorbeeld SD-WAN-oplossingen implementeren als vervanging voor traditionele IPSec VPN's op sites met alleen internetverbinding. Vervolgens gebruiken ze MPLS-services en ExpressRoute-circuits voor grote sites en datacenters, zoals wordt weergegeven in de volgende afbeelding.
Afbeelding 6. SD-WAN-oplossingen kunnen naast ExpressRoute-connectiviteit worden gebruikt wanneer SD-WAN CPE-apparaten alleen worden geïmplementeerd in een subset van sites.
Voor dit co-existentiescenario moeten SD-WAN NVA's die zijn geïmplementeerd in Azure, verkeer kunnen routeren tussen sites die zijn verbonden met de SD-WAN en sites die zijn verbonden met ExpressRoute-circuits. Routeserver kan worden geconfigureerd voor het doorgeven van routes tussen virtuele ExpressRoute-netwerkgateways en SD-WAN NVA's in Azure door de AllowBranchToBranch functie in te schakelen, zoals hier wordt beschreven. Routedoorgifte tussen de gateway van het virtuele ExpressRoute-netwerk en de SD-WAN NVA('s) vindt plaats via BGP. De routeserver brengt BGP-sessies met beide tot stand en wordt doorgegeven aan elke peer die de routes van de andere peers hebben geleerd. Het platform beheert de BGP-sessies tussen routeserver en de gateway van het virtuele ExpressRoute-netwerk. Gebruikers hoeven ze niet expliciet te configureren, maar alleen om de vlag in te schakelen bij het AllowBranchToBranch implementeren van routeserver.
Afbeelding 7. Routedoorgifte tussen de gateway van het virtuele ExpressRoute-netwerk en de SD-WAN NVA('s) vindt plaats via BGP. De routeserver brengt BGP-sessies met beide tot stand en geeft routes door in beide richtingen wanneer deze zijn geconfigureerd met 'AllowBranchToBranch=TRUE'. RouteServer fungeert als een route reflector, dat wil gezegd, het maakt geen deel uit van het gegevenspad.
Met dit co-existentiescenario voor SD-WAN en ExpressRoute kunnen migraties van MPLS-netwerken naar SD-WAN worden uitgevoerd. Het biedt een pad tussen verouderde MPLS-sites en nieuw gemigreerde SD-WAN-sites, waardoor het verkeer niet meer hoeft te worden gerouteerd via on-premises datacenters. Dit patroon kan niet alleen worden gebruikt tijdens migraties, maar ook in scenario's die voortvloeien uit fusies en overnames van bedrijven, waardoor een naadloze interconnectie van verschillende netwerken ontstaat.
Scenario 2: Expressroute als een SD-WAN-underlay
Als uw on-premises sites ExpressRoute-connectiviteit hebben, kunt u SD-WAN-apparaten configureren om tunnels in te stellen voor de NVA's van de SD-WAN-hub die worden uitgevoerd in Azure boven op het ExpressRoute-circuit of -circuits. ExpressRoute-connectiviteit kan worden uitgevoerd via punt-naar-punt-circuits of een MPLS-netwerk. U kunt zowel persoonlijke ExpressRoute-peering als de Microsoft-peering gebruiken.
Privépeering
Wanneer u de persoonlijke ExpressRoute-peering als de underlay gebruikt, brengen alle on-premises SD-WAN-sites tunnels tot stand met de NVA's van de SD-WAN-hub in Azure. Er is geen routedoorgifte tussen de SD-WAN NVA's en de gateway van het virtuele ExpressRoute-netwerk nodig in dit scenario (dat wil zeggen dat de routeserver moet worden geconfigureerd met de vlag AllowBranchToBranch die is ingesteld op false).
Voor deze aanpak is een juiste BGP-configuratie vereist voor de routers aan de klant- of providerzijde die de ExpressRoute-verbinding beëindigen. In feite kondigt de Microsoft Enterprise Edge Routers (MSEEs) alle routes aan voor de virtuele netwerken die zijn verbonden met het circuit (rechtstreeks of via peering van virtuele netwerken). Maar om verkeer dat is bestemd voor virtuele netwerken door te sturen via een SD-WAN-tunnel, moet de on-premises site deze routes leren van het SD-WAN-apparaat, niet het ER-circuit.
Daarom moeten de routers aan de klant- of providerzijde die de ExpressRoute-verbinding beëindigen, de routes filteren die zijn ontvangen van Azure. De enige routes die in de underlay zijn geconfigureerd, moeten routes zijn waarmee de on-premises SD-WAN-apparaten de NVA's van de SD-WAN-hub in Azure kunnen bereiken. Klanten die de expressRoute-privépeering willen gebruiken als sd-WAN-onderlay, moeten controleren of ze hun routeringsapparaten dienovereenkomstig kunnen configureren. Dit is vooral relevant voor klanten die geen directe controle hebben over hun edge-apparaten voor ExpressRoute. Een voorbeeld is wanneer het ExpressRoute-circuit wordt geleverd door een MPLS-provider boven op een IPVPN-service.
Afbeelding 8. Persoonlijke ExpressRoute-peering als sd-WAN-onderlay. In dit scenario ontvangen de routers aan de klant- en providerzijde de routes voor het virtuele netwerk die de ExpressRoute-verbinding beëindigen, in de BGP-sessies voor privépeering van ER en de SD-WAN CPE. Alleen de SD-WAN CPE moet de Azure-routes doorgeven aan het LAN van de site.
Microsoft-peering
U kunt de ExpressRoute Microsoft-peering ook gebruiken als een onderlay voor SD-WAN-tunnels. In dit scenario maken de NVA's van de SD-WAN-hub in Azure alleen openbare tunneleindpunten beschikbaar, die worden gebruikt door zowel SD-WAN-CPU's op sites met internetverbinding, indien aanwezig, als door SD-WAN-CPU's in sites die zijn verbonden met Expressroute. Hoewel de ExpressRoute Microsoft-peering complexere vereisten heeft dan de persoonlijke peering, raden we u aan deze optie als onderlay te gebruiken vanwege deze twee voordelen:
Er zijn geen expressroute-gateways voor virtuele netwerken in het virtuele hubnetwerk vereist. Het verwijdert complexiteit, vermindert de kosten en laat de SD-WAN-oplossing buiten de bandbreedtelimieten van de gateway zelf schalen wanneer u ExpressRoute FastPath niet gebruikt.
Het biedt een schone scheiding tussen overlay- en onderlayroutes. De MSE's kondigen alleen de openbare voorvoegsels van het Microsoft-netwerk aan voor de edge van de klant of provider. U kunt deze routes in een afzonderlijke VRF beheren en alleen doorgeven aan een DMZ-segment van het LAN van de site. SD-WAN-apparaten doorgeven de routes voor het bedrijfsnetwerk van de klant in de overlay, inclusief routes voor virtuele netwerken. Klanten die deze aanpak overwegen, moeten controleren of ze hun routeringsapparaten dienovereenkomstig kunnen configureren of de juiste service kunnen aanvragen bij hun MPLS-provider.
Overwegingen voor MPLS
Migratie van traditionele MPLS-bedrijfsnetwerken naar modernere netwerkarchitecturen op basis van het SD-WAN-paradigma vereist een aanzienlijke inspanning en een aanzienlijke hoeveelheid tijd. De architectuur die in dit artikel wordt beschreven, maakt gefaseerde SD-WAN-migraties mogelijk. Later worden twee typische migratiescenario's besproken.
Gefaseerde MPLS buiten gebruik stellen
Klanten die een SD-WAN willen bouwen boven op het openbare internet en de Microsoft-backbone, en volledig buiten gebruik willen stellen van MPLS IPVPN's of andere toegewezen connectiviteitsservices, kunnen gebruikmaken van het co-existentiescenario van ExpressRoute en SD-WAN dat in de vorige sectie tijdens de migratie wordt beschreven. Hiermee kunnen met SD-WAN verbonden sites sites bereiken die nog steeds zijn verbonden met de verouderde MPLS. Zodra een site wordt gemigreerd naar de SD-WAN- en CPE-apparaten, kan de MPLS-koppeling buiten gebruik worden gesteld. De site heeft toegang tot het hele bedrijfsnetwerk via de SD-WAN-tunnels naar de dichtstbijzijnde Azure-regio's.
Afbeelding 9. Het co-existentiescenario 'ExpressRoute en SD-WAN' maakt gefaseerde MPLS-buitengebruikstelling mogelijk.
Wanneer alle sites worden gemigreerd, kan de MPLS IPVPN buiten gebruik worden gesteld, samen met de ExpressRoute-circuits die deze verbinden met de Microsoft-backbone. Virtuele ExpressRoute-netwerkgateways zijn niet meer nodig en kunnen ongedaan worden gemaakt. De NVA's van de SD-WAN-hub in elke regio worden het enige toegangspunt in het hub- en spoke-netwerk van die regio.
MPLS-integratie
Organisaties die geen openbare en gedeelde netwerken vertrouwen om de gewenste prestaties en betrouwbaarheid te bieden, kunnen besluiten om een bestaand MPLS-netwerk te gebruiken als een onderlay van bedrijfsklasse. Er zijn twee opties:
- Een subset van sites zoals datacenters of grote filialen.
- Een subset van verbindingen, meestal latentiegevoelig of bedrijfskritiek verkeer.
Het scenario Expressroute als een SD-WAN-underlay die eerder is beschreven, maakt integratie van SD-WAN en MPLS mogelijk. De ExpressRoute Microsoft-peering moet de voorkeur hebben boven de persoonlijke peering om de redenen die eerder zijn besproken. Wanneer de Microsoft-peering wordt gebruikt, worden het MPLS-netwerk en het openbare internet functioneel equivalente onderlays. Ze bieden toegang tot alle SD-WAN-tunneleindpunten die worden weergegeven door NVA's van sd-WAN-hubs in Azure. Een SD-WAN CPE die is geïmplementeerd op een site met zowel internet- als MPLS-connectiviteit, kan meerdere tunnels tot stand brengen met de SD-WAN-hubs in Azure op beide onderlays. Ze kunnen vervolgens verschillende verbindingen routeren via verschillende tunnels, op basis van beleid op toepassingsniveau dat wordt beheerd door het SD-WAN-besturingsvlak.
Afbeelding 10. Het scenario 'ExpressRoute als een SD-WAN-underlay' maakt integratie van SD-WAN en MPLS mogelijk.
Routeringsvoorkeur voor routeserver
In beide MPLS-scenario's die in de twee vorige secties zijn behandeld, kunnen sommige vertakkingssites worden verbonden met de MPLS IPVPN en met de SD-WAN. Als gevolg hiervan kunnen de routeserverexemplaren die zijn geïmplementeerd in de virtuele hubnetwerken, dezelfde routes leren van ExpressRoute-gateways en SD-WAN NVA's. Met routeringsvoorkeur voor routeservers kunt u bepalen welk pad de voorkeur moet krijgen en in de routetabellen van de virtuele netwerken moeten worden opgenomen. Routeringsvoorkeur is handig wanneer as-padvoorverlening niet kan worden gebruikt. Een voorbeeld hiervan zijn MPLS IPVPN-services die geen ondersteuning bieden voor aangepaste BGP-configuraties op de PEs die ExpressRoute-verbindingen beëindigen.
Limieten en ontwerpoverwegingen voor routeserver
Route Server is de hoeksteen van de architectuur die in dit artikel wordt beschreven. Er worden routes doorgegeven tussen SD-WAN NVA's die zijn geïmplementeerd in virtuele netwerken en de onderliggende Azure SDN-stack. Het biedt een op BGP gebaseerde benadering voor het uitvoeren van meerdere SD-WAN NVA's voor hoge beschikbaarheid en horizontale schaalbaarheid. Wanneer u grote SD-WAN's ontwerpt op basis van deze architectuur, moeten de schaalbaarheidslimieten van Route Server worden meegerekend.
De volgende secties bevatten richtlijnen voor schaalbaarheidslimieten en hoe u elke limiet kunt verwerken.
Routes die worden geadverteerd door een BGP-peer naar routeserver
Routeringsserver definieert geen expliciete limiet voor het aantal routes dat kan worden geadverteerd naar ExpressRoute Virtual Network Gateways wanneer de AllowBranchToBranch vlag is ingesteld. ExpressRoute-gateways geven echter de routes die ze leren van routeserver door naar de ExpressRoute-circuits waar ze mee zijn verbonden.
Er is een limiet voor het aantal routes dat ExpressRoute-gateways kunnen adverteren naar ExpressRoute-circuits via de persoonlijke peering, die zijn gedocumenteerd op azure-abonnements- en servicelimieten, quota en beperkingen. Bij het ontwerpen van SD-WAN-oplossingen op basis van de richtlijnen in dit artikel is het essentieel om ervoor te zorgen dat SD-WAN-routes deze limiet niet bereiken. Als dit wordt bereikt, worden de BGP-sessies tussen ExpressRoute-gateways en ExpressRoute-circuits verbroken en gaat de verbinding tussen virtuele netwerken en externe netwerken die zijn verbonden via ExpressRoute verloren.
Het totale aantal routes dat wordt geadverteerd naar circuits door ExpressRoute-gateways is de som van het aantal routes dat is geleerd van routeserver en het aantal voorvoegsels waaruit de adresruimte van het Azure-hub- en spoke-netwerk bestaat. Om storingen vanwege verwijderde BGP-sessies te voorkomen, raden we u aan de volgende oplossingen te implementeren:
- Gebruik de functies van systeemeigen SD-WAN-apparaten om het aantal routes dat wordt aangekondigd voor routeserver te beperken, als de functie beschikbaar is.
- Gebruik Azure Monitor-waarschuwingen om proactief pieken te detecteren in het aantal routes dat wordt aangekondigd door ExpressRoute-gateways. De meetwaarde die moet worden bewaakt heeft de naam Aantal routes dat is geadverteerd naar peer, zoals beschreven in ExpressRoute-bewaking.
BGP-peers
RouteServer kan BGP-sessies tot stand brengen met maximaal een maximum aantal BGP-peers. Deze limiet bepaalt het maximum aantal SD-WAN NVA's dat BGP-aangrenzing kan vaststellen met Route Server, en daarom de maximale geaggregeerde doorvoer die kan worden ondersteund in alle SD-WAN-tunnels. Er wordt verwacht dat alleen grote SD-WAN's deze limiet bereiken. Er bestaan geen tijdelijke oplossingen om deze te overwinnen, behalve het maken van meerdere hub- en spoke-netwerken, elk met eigen gateways en routeservers.
Deelnemende VM's
Virtuele netwerkgateways en routeserver configureren de routes die ze leren van hun externe peers voor alle VM's in hun eigen virtuele netwerk en in rechtstreeks gekoppelde virtuele netwerken. Om routeserver te beschermen tegen overmatig resourceverbruik vanwege routeringsupdates naar VM's, definieert Azure een limiet voor het aantal VIRTUELE machines dat in één hub en spoke-netwerk kan bestaan. Er bestaan geen tijdelijke oplossingen om deze limiet te overwinnen, behalve het maken van meerdere hub- en spoke-netwerken, elk met eigen gateways en routeservers, in dezelfde regio.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Belangrijkste auteurs:
- Microsoft Guerrini | Senior Cloud Solution Architect
- De Kaviraj | Cloud Solution Architect
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.