Scenario: BGP-peering med en virtuell hubb
Azure Virtual WAN-hubbrouter, även kallad virtuell hubbrouter, fungerar som routningshanterare och förenklar routningsåtgärden inom och över virtuella hubbar. Med andra ord gör en virtuell hubbrouter följande:
- Förenklar routningshanteringen genom att vara den centrala routningsmotorn som pratar med gatewayer som VPN, ExpressRoute, P2S och NVA (Network Virtual Appliances).
- Möjliggör avancerade routningsscenarier för anpassade routningstabeller, associationer och spridning av vägar.
- Fungerar som router för trafiköverföring mellan/till virtuella nätverk som är anslutna till en virtuell hubb.
Nu exponerar även den virtuella hubbroutern möjligheten till peerkoppling, där routningsinformation utbyts direkt via BGP-routningsprotokollet (Border Gateway Protocol). NVA eller en BGP-slutpunkt som har etablerats i ett virtuellt nätverk som är anslutet till en virtuell hubb kan peerkopplas direkt till den virtuella hubbroutern om den stöder BGP-routningsprotokollet och säkerställer att ASN på NVA:n är konfigurerad annorlunda än den virtuella hubbens ASN.
Fördelar och överväganden
Viktiga fördelar
- Du behöver inte längre uppdatera routningstabellen manuellt på din NVA när dina virtuella nätverksadresser uppdateras.
- Du behöver inte längre uppdatera användardefinierade vägar manuellt när din NVA meddelar nya vägar eller drar tillbaka gamla.
- NVA i virtuella nätverk som är anslutna till en virtuell hubb kan lära sig vägar för virtuell hubbgateway (VPN, ExpressRoute eller Managed NVA).
- Du kan peer-koppla flera instanser av din NVA med en virtuell hubbrouter. Du kan konfigurera BGP-attribut i din NVA och, beroende på din design (aktiv-aktiv eller aktiv-passiv), låta den virtuella hubbroutern veta vilken NVA-instans som är aktiv eller passiv.
Överväganden
Du kan inte peer-koppla en virtuell hubbrouter med Azure Route Server etablerad i ett virtuellt nätverk.
Den virtuella hubbroutern stöder endast 16-bitars (2 byte) ASN.
Den virtuella nätverksanslutning som har NVA BGP-anslutningsslutpunkten måste alltid associeras och spridas till defaultRouteTable. Anpassade routningstabeller stöds inte just nu.
Routern för den virtuella hubben stöder överföringsanslutning mellan virtuella nätverk som är anslutna till virtuella hubbar. Detta har inget att göra med den här funktionen för BGP-peeringfunktionen eftersom Virtual WAN redan stöder överföringsanslutning. Exempel:
- VNET1: NVA1 ansluten till Virtual Hub 1 –> (överföringsanslutning) –> VNET2: NVA2 ansluten till Virtual Hub 1.
- VNET1: NVA1 ansluten till Virtual Hub 1 –> (överföringsanslutning) –> VNET2: NVA2 ansluten till Virtual Hub 2.
Du kan använda dina egna offentliga ASN:er eller privata ASN:er i din virtuella nätverksinstallation. Du kan inte använda de intervall som är reserverade av Azure eller IANA. Följande ASN reserveras av Azure eller IANA:
- ASN reserverade av Azure:
- Offentliga ASN:er: 8074, 8075, 12076
- Privata ASN:er: 65515, 65517, 65518, 65519, 65520
- ASN reserverade av IANA: 23456, 64496-64511, 65535-65551
- ASN reserverade av Azure:
Även om den virtuella hubbroutern utbyter BGP-vägar med din NVA och sprider dem till ditt virtuella nätverk, underlättar den direkt spridning av vägar från den lokala miljön via den virtuella hubbens värdbaserade gatewayer (VPN-gateway/ExpressRoute-gateway/hanterade NVA-gatewayer).
BGP-peering stöds endast med en IP-adress som är tilldelad till ett gränssnitt för NVA. Peering med loopbacks stöds inte.
Routern för den virtuella hubben har följande gränser:
Resurs Gräns Antal vägar som varje BGP-peer kan annonsera till den virtuella hubben. Hubben kan bara acceptera ett maximalt antal 10 000 vägar (totalt) från sina anslutna resurser. Om en virtuell hubb till exempel har totalt 6 000 vägar från de anslutna virtuella nätverken, grenarna, virtuella hubbar osv. kan NVA bara annonsera upp till 4 000 vägar när en ny BGP-peering har konfigurerats med en NVA. Antal BGP-peer-datorer Högst 8 BGP-peer-datorer kan anslutas till en enda Virtuell WAN-hubb Vägar från NVA i ett virtuellt nätverk som är mer specifika än det virtuella nätverkets adressutrymme, när de annonseras till den virtuella hubben via BGP sprids inte vidare till lokalt.
För närvarande stöder vi bara 4 000 vägar från NVA till den virtuella hubben.
Trafik som är avsedd för adresser i det virtuella nätverket som är direkt ansluten till den virtuella hubben kan inte konfigureras för att dirigera via NVA med BGP-peering mellan hubben och NVA. Det beror på att den virtuella hubben automatiskt lär sig om systemvägar som är associerade med adresser i det virtuella ekernätverket när den virtuella ekernätverksanslutningen skapas. Dessa automatiskt inlärda systemvägar föredras framför vägar som hubben har lärt sig via BGP.
BGP-peering mellan en NVA i ett virtuellt ekernätverk och en säker virtuell hubb (hubb med en integrerad säkerhetslösning) stöds om routnings avsikten har konfigurerats på hubben. BGP-peeringfunktionen stöds inte för skyddade virtuella hubbar där routningssyftet inte har konfigurerats.
För att NVA ska kunna byta vägar med VPN- och ER-anslutna platser måste förgrening till grendirigering vara aktiverad.
När du konfigurerar BGP-peering med hubben visas två IP-adresser. Peering med båda dessa adresser krävs. Inte peering med båda adresserna kan orsaka routningsproblem. Samma vägar måste annonseras till båda dessa adresser. Annonsering av olika vägar orsakar routningsproblem.
Nästa hopp-IP-adress på de vägar som annonseras från NVA till den virtuella HUB-routningsservern måste vara samma som IP-adressen för NVA, IP-adressen som konfigurerats på BGP-peer.the next hop IP address on the routes being advertised from the NVA to the virtual HUB route server to the next hop IP address on the routes being advertised from the NVA to the virtual HUB route server has to be same as the IP address of the NVA, the IP address configured on the BGP peer. Att ha en annan IP-adress som annonseras som nästa hopp stöds INTE på virtual WAN för tillfället.
BGP-peeringscenarier
I det här avsnittet beskrivs scenarier där BGP-peeringfunktionen kan användas för att konfigurera routning.
Överföring av VNet-anslutning
I det här scenariot är den virtuella hubben med namnet "Hub 1" ansluten till flera virtuella nätverk. Målet är att upprätta routning mellan virtuella nätverk VNET1 och VNET5.
Konfigurationssteg utan BGP-peering
Följande steg krävs när BGP-peering inte används på den virtuella hubben:
Konfiguration av virtuell hubb
- På Hub 1:s defaultRouteTable konfigurerar du statisk väg för VNET5 (undernät 10.2.1.0/24) som pekar på VNET2-anslutning.
- På Hub 1:s virtuella nätverksanslutning för VNET2 konfigurerar du statisk väg för VNET5 som pekar på VNET2 NVA IP (undernät 10.2.0.5).
- På Hub 1 sprider du vägar från anslutningar för VNET1 och VNET2 till defaultRouteTable och associerar dem till defaultRouteTable.
Konfiguration av virtuellt nätverk
- På VNET5 konfigurerar du en användardefinierad väg (UDR) för att peka på VNET2 NVA IP.
Konfigurationssteg med BGP-peering
I den tidigare konfigurationen kan underhållet av statiska vägar och UDR bli komplext om VNET5-konfigurationen ändras ofta. För att hantera den här utmaningen kan BGP-peering med en virtuell hubbfunktion användas och routningskonfigurationen måste ändras till följande steg:
Konfiguration av virtuell hubb
- På Hub 1 konfigurerar du VNET2 NVA som en BGP-peer. Konfigurera även VNET2 NVA för att ha en BGP-peering med Hub 1.
- På Hub 1 sprider du vägar från anslutningar för VNET1 och VNET2 till defaultRouteTable och associerar dem till defaultRouteTable.
Konfiguration av virtuellt nätverk
- På VNET5 konfigurerar du en användardefinierad väg (UDR) för att peka på VNET2 NVA IP.
Gällande routningar
I följande tabell visas några poster från Hub 1:s effektiva vägar i defaultRouteTable. Observera att vägen för VNET5 (undernät 10.2.1.0/24) och detta bekräftar att VNET1 och VNET5 kommer att kunna kommunicera med varandra.
| Målprefix | Nästa hopp | Ursprung | ASN-sökväg |
|---|---|---|---|
| 10.2.0.0/24 | eastusconn | VNet-anslutnings-ID | - |
| 10.2.1.0/24 | BGP-peeranslutnings-ID för NVA | BGP-peeranslutnings-ID för NVA | 65510 |
| 10.4.1.0/24 | Hubb 2 | Hubb 2 | - |
Om du konfigurerar routning på det här sättet med funktionen eliminerar du behovet av statiska routningsposter på den virtuella hubben. Därför är konfigurationen enklare och routningstabellerna uppdateras dynamiskt när konfigurationen i anslutna virtuella nätverk (till exempel VNET5) ändras.
Anslutning till gren-VNet
I det här scenariot har den lokala platsen med namnet "NVA Branch 1" ett VPN som är konfigurerat att avslutas på VNET2 NVA. Målet är att konfigurera routning mellan NVA Branch 1 och VNET1 för virtuellt nätverk.
Konfigurationssteg utan BGP-peering
Följande steg krävs när BGP-peering inte används på den virtuella hubben:
Konfiguration av virtuell hubb
- På Hub 1:s defaultRouteTable konfigurerar du statisk väg för NVA Branch 1 som pekar på VNET2-anslutning.
- På Hub 1:s virtuella nätverksanslutning för VNET2 konfigurerar du statisk väg för NVA Branch 1 som pekar på VNET2 NVA IP (10.2.0.5).
- På Hub 1 sprider du vägar från anslutningar för VNET1 och VNET2 till defaultRouteTable och associerar dem med defaultRouteTable.
Konfiguration av virtuellt nätverk
- BGP-peering mellan VNET2 NVA och NVA Branch 1 och dirigera annonser för VNET1 från VNET2 NVA till NVA Branch 1.
Konfigurationssteg med BGP-peering
Med tiden kan målprefixen i NVA Branch 1 ändras, eller så kan det finnas många platser som NVA Branch 1, som behöver anslutning till VNET1. Detta skulle leda till att du behöver uppdateringar av de statiska vägarna på Hub 1- och VNET2-anslutningen, vilket kan bli besvärligt. I sådana fall kan vi använda BGP-peering med en virtuell hubbfunktion och konfigurationsstegen för routningsanslutning skulle vara som anges nedan.
Konfiguration av virtuell hubb
- På Hub 1 konfigurerar du VNET2 NVA som en BGP-peer. Konfigurera även VNET2 NVA för att ha en BGP-peering med Hub 1.
- På Hub 1 sprider du vägar från anslutningar för VNET1 och VNET2 till defaultRouteTable och associerar dem med defaultRouteTable.
Konfiguration av virtuellt nätverk
- BGP-peering mellan VNET2 NVA och NVA Branch 1 och dirigera annonser för VNET1 från VNET2 NVA till NVA Branch 1.
Gällande routningar
Tabellen nedan visar några poster från Hub 1:s effektiva vägar i defaultRouteTable. Observera att vägen för NVA Branch 1 (undernät 192.168.1.0/24) har lärts över BGP-peering med NVA.
| Målprefix | Nästa hopp | Ursprung | ASN-sökväg |
|---|---|---|---|
| 10.2.0.0/24 | eastusconn | VNet-anslutnings-ID | - |
| 192.168.1.0/24 | BGP-peeranslutnings-ID för NVA | BGP-peeranslutnings-ID för NVA | 65510 |
För att hantera nätverksändringar i NVA Branch 1 eller upprätta anslutning mellan nya platser som NVA Branch 1 krävs ingen ytterligare konfiguration på Hub 1 eftersom BGP-peering mellan Hub 1 och NVA dynamiskt uppdaterar routningstabellerna. Konfigurationen och underhållet förenklas därför.