Erstellen eines benutzerdefinierten IPv6-Adresspräfixes mithilfe von Azure PowerShell

Mit einem benutzerdefinierten IPv6-Adresspräfix können Sie Ihre eigenen IPv6-Bereiche auf Microsoft-Ressourcen verwenden und Ihrem Azure-Abonnement zuordnen. Sie sind weiterhin im Besitz des Bereichs, aber Microsoft ist es gestattet, ihn im Internet anzukündigen. Ein benutzerdefiniertes IP-Adresspräfix fungiert als regionale Ressource, die einen zusammenhängenden Block kundeneigener IP-Adressen darstellt.

Dieser Artikel bietet ausführliche Anleitungen für folgende Aufgaben:

  • Vorbereiten eines Bereichs für die Bereitstellung

  • Bereitstellen des Bereichs für die IP-Zuweisung

  • Aktivieren des Bereichs für die Ankündigung durch Microsoft

Unterschiede zwischen der Verwendung von BYOIPv4 und BYOIPv6

Wichtig

Integrierte benutzerdefinierte IPv6-Adresspräfixe verfügen über mehrere eindeutige Attribute, die sie von benutzerdefinierten IPv4-Adresspräfixen unterscheiden.

  • Benutzerdefinierte IPv6-Präfixe verwenden ein Modell mit übergeordneten Elementen/untergeordneten Elementen. In diesem Modell kündigt das Microsoft Wide Area Network (WAN) den globalen (übergeordneten) Bereich an, und die jeweiligen Azure-Regionen kündigen die regionalen (untergeordneten) Bereiche an. Globale Bereiche müssen die Größe /48 aufweisen, während regionale Bereiche immer die Größe /64 haben müssen. Sie können mehrere /64-Bereiche pro Region haben.

  • Nur der globale Bereich muss mithilfe der Schritte im Artikel Erstellen benutzerdefinierter IP-Adresspräfixe überprüft werden. Die regionalen Bereiche werden aus dem globalen Bereich abgeleitet, ähnlich wie öffentliche IP-Präfixe aus benutzerdefinierten IP-Präfixen abgeleitet werden.

  • Öffentliche IPv6-Präfixe müssen aus den regionalen Bereichen abgeleitet werden. Nur die ersten 2.048 IPv6-Adressen jedes regionalen benutzerdefinierten /64-IP-Präfixes können als gültiger IPv6-Bereich verwendet werden. Der Versuch, öffentliche IPv6-Präfixe außerhalb dieses Adressraums zu erstellen, führt zu einem Fehler.

Voraussetzungen

  • Ein Azure-Konto mit einem aktiven Abonnement. Sie können kostenlos ein Konto erstellen.
  • Azure PowerShell (lokale Installation) oder Azure Cloud Shell.
  • Melden Sie sich bei Azure PowerShell an, und stellen Sie sicher, dass Sie das Abonnement ausgewählt haben, mit dem Sie dieses Feature verwenden möchten. Weitere Informationen finden Sie unter Anmelden mit Azure PowerShell.
  • Stellen Sie sicher, dass Ihr Az.Network-Modul Version 5.1.1 oder höher aufweist. Um das installierte Modul zu überprüfen, verwenden Sie den Befehl Get-InstalledModule -Name "Az.Network". Falls das Modul ein Update erfordert, verwenden Sie bei Bedarf den Befehl Update-Module -Name "Az.Network".
  • Ein IPv6-Adressbereich im Besitz der Kunden, die in Azure bereitgestellt werden sollen. Für dieses Beispiel wird ein Beispielkundenbereich (2a05:f500:2::/48) verwendet, der jedoch nicht von Azure überprüft wird. Sie müssen den Beispielbereich durch Ihren eigenen Bereich ersetzen.

Wenn Sie PowerShell lokal installieren und verwenden möchten, müssen Sie für diesen Artikel mindestens Version 5.4.1 des Azure PowerShell-Moduls verwenden. Führen Sie Get-Module -ListAvailable Az aus, um die installierte Version zu ermitteln. Wenn Sie ein Upgrade ausführen müssen, finden Sie unter Installieren des Azure PowerShell-Moduls Informationen dazu. Wenn Sie PowerShell lokal ausführen, müssen Sie auch Connect-AzAccount ausführen, um eine Verbindung mit Azure herzustellen.

Hinweis

Hilfe bei Problemen während des Bereitstellungsprozesses finden Sie unter Problembehandlung für benutzerdefinierte IP-Präfixe.

Vor der Bereitstellung auszuführende Schritte

Um das BYOIP-Feature von Azure zu nutzen, müssen Sie vor der Bereitstellung Ihres IPv6-Adressbereichs einige Schritte ausführen. Weitere Details finden Sie in den IPv4-Anweisungen. Beachten Sie, dass alle diese Schritte für den globalen (übergeordneten) IPv6-Bereich durchgeführt werden müssen.

Bereitstellung für IPv6

Die folgenden Schritte zeigen die spezielle Vorgehensweise für die Bereitstellung eines globalen (übergeordneten) IPv6-Beispielbereichs (2a05:f500:2::/48) und regionaler (untergeordneter) IPv6-Bereiche. Einige der Schritte aus den IPv4-Anweisungen wurden gekürzt oder komprimiert, um die Unterschiede zwischen IPv4 und IPv6 zu verdeutlichen.

Erstellen einer Ressourcengruppe und Angeben der Präfix- und Autorisierungsnachrichten

Erstellen Sie eine Ressourcengruppe am gewünschten Standort für die Bereitstellung des globalen Bereichs.

Wichtig

Obwohl die Ressource für den globalen Bereich einer Region zugeordnet wird, wird das Präfix von Microsoft WAN global angekündigt.

$rg =@{
    Name = 'myResourceGroup'
    Location = 'WestUS2'
}
New-AzResourceGroup @rg

Bereitstellen eines globalen benutzerdefinierten IPv6-Adresspräfixes

Der folgende Befehl erstellt ein benutzerdefiniertes IP-Adresspräfix in der angegebenen Region und Ressourcengruppe. Geben Sie das genaue Präfix in CIDR-Notation als Zeichenfolge an, um sicherzustellen, dass keine Syntaxfehler auftreten. (Die Parameter -AuthorizationMessage und -SignedMessage werden auf dieselbe Weise wie für IPv4 erstellt. Weitere Informationen finden Sie unter Erstellen eines benutzerdefinierten IP-Präfixes – PowerShell.) Es werden keine Zoneneigenschaften angegeben, da der globale Bereich keiner bestimmten Region zugeordnet ist (und es daher keine regionalen Verfügbarkeitszonen gibt).

$prefix =@{
    Name = 'myCustomIPv6GlobalPrefix'
    ResourceGroupName = 'myResourceGroup'
    Location = 'WestUS'
    CIDR = '2a05:f500:2::/48'
    AuthorizationMessage = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|2a05:f500:2::/48|yyyymmdd'
    SignedMessage = $byoipauthsigned
}
$myCustomIPv6GlobalPrefix = New-AzCustomIPPrefix @prefix

Bereitstellen eines regionalen benutzerdefinierten IPv6-Adresspräfixes

Nachdem sich das globale benutzerdefinierte IP-Präfix im Zustand Bereitgestellt befindet, können regionale benutzerdefinierte IP-Präfixe erstellt werden. Diese Bereiche müssen immer die Größe /64 aufweisen, um als gültig betrachtet zu werden. Die Bereiche können in jeder Region erstellt werden (sie muss nicht mit der für das globale benutzerdefinierte IP-Präfix übereinstimmen), wobei alle Geolocation-Einschränkungen im Zusammenhang mit dem ursprünglichen globalen Bereich zu berücksichtigen sind. Die „untergeordneten“ benutzerdefinierten IP-Präfixe werden lokal aus der Region angekündigt, in der sie erstellt werden. Da die Überprüfung nur für die Bereitstellung des globalen benutzerdefinierten IP-Präfixes erfolgt, ist keine Autorisierungs- oder Signaturnachricht erforderlich. (Da diese Bereiche aus einer bestimmten Region angekündigt werden, können Zonen genutzt werden.)

$prefix =@{
    Name = 'myCustomIPv6RegionalPrefix'
    ResourceGroupName = 'myResourceGroup'
    Location = 'EastUS2'
    CIDR = '2a05:f500:2:1::/64'
}
$myCustomIPv6RegionalPrefix = New-AzCustomIPPrefix @prefix -Zone 1,2,3

Ähnlich wie bei benutzerdefinierten IPv4-Präfixen können öffentliche IP-Präfixe, nachdem das regionale benutzerdefinierte IP-Präfix den Status Bereitgestellt aufweist, aus dem regionalen benutzerdefinierten IP-Präfix abgeleitet werden. Diese öffentlichen IP-Präfixe und alle von ihnen abgeleiteten öffentlichen IP-Adressen können an Netzwerkressourcen angefügt werden, obwohl sie noch nicht angekündigt werden.

Wichtig

Öffentliche IPv6-Präfixe, die von regionalen benutzerdefinierten IPv6-Präfixen abgeleitet wurden, können nur die ersten 2.048 IP-Adressen des /64-Bereichs verwenden.

Kommissionieren der benutzerdefinierten IPv6-Adresspräfixe

Bei der Kommissionierung benutzerdefinierter IPv6-Präfixe werden die globalen und regionalen Präfixe separat verarbeitet. Mit anderen Worten: Die Kommissionierung eines regionalen benutzerdefinierten IPv6-Präfixes hängt nicht mit der Kommissionierung des globalen benutzerdefinierten IPv6-Präfixes zusammen.

Abbildung des benutzerdefinierten IPv6-Präfixes mit übergeordnetem Präfix und untergeordneten Präfixen in mehreren Regionen

Die sicherste Strategie für Bereichsmigrationen ist die folgende:

  1. Stellen Sie alle erforderlichen regionalen IPv6-Präfixe in ihren jeweiligen Regionen bereit. Erstellen Sie öffentliche IPv6-Präfixe und öffentliche IP-Adressen, und fügen Sie sie an Ressourcen an.
  2. Kommissionieren Sie jedes regionale benutzerdefinierte IPv6-Präfix, und testen Sie die Konnektivität mit den IP-Adressen innerhalb der Region. Wiederholen Sie den Vorgang für jedes regionale benutzerdefinierte IPv6-Präfix.
  3. Wenn alle regionalen benutzerdefinierten IPv6-Präfixe (und die abgeleiteten Präfixe/IP-Adressen) wie erwartet funktionieren, kommissionieren Sie das globale benutzerdefinierte IPv6-Präfix, das den größeren Bereich im Internet ankündigt.

Bei den obigen Beispielbereichen lautet die Befehlssequenz wie folgt:

Update-AzCustomIpPrefix -ResourceId $myCustomIPv6RegionalPrefix.Id -Commission

Gefolgt von:

Update-AzCustomIpPrefix -ResourceId $myCustomIPv6GlobalPrefix.Id -Commission

Hinweis

Die geschätzte Zeit bis zum vollständigen Abschluss des Inbetriebnahmeprozesses für ein benutzerdefiniertes globales IPv6-Präfix beträgt 3-4 Stunden. Die geschätzte Zeit bis zum vollständigen Abschluss des Inbetriebnahmeprozesses für ein benutzerdefiniertes regionales IPv6-Präfix beträgt 30 Minuten.

Es ist möglich, das globale benutzerdefinierte IPv6-Präfix vor den regionalen benutzerdefinierten IPv6-Präfixen zu kommissionieren. Dadurch wird der globale Bereich im Internet angekündigt, bevor die regionalen Präfixe bereit sind – dies wird für Migrationen aktiver Bereiche nicht empfohlen. Sie können ein globales benutzerdefiniertes IPv6-Präfix stilllegen, solange noch aktive regionale benutzerdefinierte IPv6-Präfixe vorhanden sind. Sie können auch ein regionales benutzerdefiniertes IP-Präfix stilllegen, während das globale Präfix weiterhin aktiv ist.

Wichtig

Sobald das globale benutzerdefinierte IPv6-Präfix den Zustand In Betrieb gesetzt annimmt, wird der Bereich von Microsoft aus der lokalen Azure-Region und global für das Internet durch das WAN von Microsoft unter der ASN 8075 (Autonomous System Number) angekündigt. Denselben Bereich im Internet von einem anderen Standort als Microsoft aus gleichzeitig anzukündigen könnte instabiles BGP-Routing-Instabilität oder verlorenen Traffic zur Folge haben. Etwa von einem Kundenstandort aus. Planen Sie eine Migration eines aktiven Bereichs während eines Wartungszeitraums, um Beeinträchtigungen zu vermeiden.

Nächste Schritte