Compartir a través de

Finalización de las tareas previas necesarias para implementar una red móvil privada

  • Artículo

En esta guía paso a paso, realizará cada una de las tareas necesarias para poder implementar una red móvil privada mediante Azure Private 5G Core.

Sugerencia

Los requisitos de diseño de una red móvil privada contienen los requisitos de diseño de red completos para una red personalizada.

Herramientas y acceso

Para implementar la red móvil privada mediante Azure Private 5G Core, necesita lo siguiente:

Obtención de acceso a Azure Private 5G Core para la suscripción a Azure

Póngase en contacto con el ingeniero de pruebas y pídale que registre su suscripción a Azure para acceder a Azure Private 5G Core. Si aún no tiene un ingeniero de pruebas y está interesado en probar Azure Private 5G Core, póngase en contacto con el equipo de su cuenta de Microsoft o rellene el formulario de registro de partners.

Elija el tipo de tecnología principal (5G, 4G o 4G combinado y 5G)

Elija si cada sitio de la red móvil privada debe proporcionar cobertura para equipos de usuario 5G, 4G o 4G y 5G combinado. Si va a implementar varios sitios, cada uno puede admitir diferentes tipos de tecnología principales.

Elección de una implementación estándar o de alta disponibilidad

Azure Private 5G Core se implementa como un clúster de Azure Kubernetes Service (AKS). Este clúster se puede ejecutar en un único dispositivo de Azure Stack Edge (ASE) o en un par de dispositivos ASE para un servicio de alta disponibilidad (HA). Una implementación de alta disponibilidad permite mantener el servicio en caso de un error de hardware de ASE.

Para una implementación de alta disponibilidad, deberá implementar un enrutador de puerta de enlace (estrictamente, un dispositivo compatible con la capa 3: un enrutador o un conmutador L3 [enrutador o conmutador híbrido]) entre el clúster de ASE y:

  • el equipo RAN en la red de acceso.
  • las redes de datos.

El enrutador de puerta de enlace debe admitir la detección de reenvío bidireccional (BFD) y SFP compatibles con Mellanox (módulos acoplables de factor de forma pequeño).

Debe diseñar la red para tolerar errores de un enrutador de puerta de enlace en la red de acceso o en una red de datos. AP5GC solo admite una dirección IP de enrutador de puerta de enlace única por red. Por lo tanto, solo se admite un diseño de red en el que haya un enrutador de puerta de enlace único por red o donde los enrutadores de puerta de enlace se implementen en pares redundantes en una configuración activo-en espera con una dirección IP de puerta de enlace flotante. Los enrutadores de puerta de enlace de cada par redundante deben supervisarse entre sí mediante VRRP (Virtual Router Redundancy Protocol) para proporcionar la detección de errores de asociado.

Topologías de red de clúster

La alta disponibilidad de AP5GC se basa en una plataforma que consta de un clúster de dos nodos de dispositivos ASE. Los ASE están conectados a una subred IP y un dominio de difusión L2 común en la red de acceso (o bien dos dominios L2 comunes, uno para N2 y otro para N3, mediante redes VLAN) y en cada una de las redes principales. También comparten un dominio de difusión L2 y una subred IP en la red de administración.

Consulte Topologías de red admitidas. Se recomienda usar la opción 1: el puerto 1 y el puerto 2 están en subredes diferentes. Se crean conmutadores virtuales independientes. El puerto 3 y el puerto 4 se conectan a un conmutador virtual externo.

Consulte Topologías de red admitidas. Se recomienda usar la opción 2: uso de conmutadores y formación de equipos NIC para la máxima protección frente a errores. Aunque también es aceptable usar un conmutador si se prefiere (opción 3), esto provocará un mayor riesgo de tiempo de inactividad en caso de que se produzca un error del conmutador. El uso de la topología sin conmutador (opción 1) es posible, pero no se recomienda debido al riesgo aún mayor de tiempo de inactividad. La opción 3 hace que cada ASE cree automáticamente un conmutador virtual de Hyper-V (vswitch) y agregue los puertos a él.

Cuórum de clúster y testigo

Un clúster de ASE de dos nodos requiere un testigo de clúster, de modo que, si se produce un error en uno de los nodos de ASE, el testigo de clúster representa el tercer voto y el clúster permanece en línea. El testigo de clúster se ejecuta en la nube de Azure.

Para configurar un testigo en la nube de Azure, consulte https://learn.microsoft.com/windows-server/failover-clustering/deploy-cloud-witness. El campo Replicación debe establecerse en el almacenamiento con redundancia local (LRS). Los firewalls entre el clúster de ASE y la cuenta de almacenamiento de Azure deben permitir el tráfico saliente a https://.core.windows.net/ en el puerto 443 (HTTPS).

Asignación de subredes y direcciones IP

Azure Private 5G Core requiere una red de administración, una red de acceso y hasta diez redes de datos. Estas redes pueden formar parte de la misma red más grande o pueden ser independientes. El enfoque que use dependerá de los requisitos de separación del tráfico.

Para cada una de estas redes, asigne una subred e identifique las direcciones IP enumeradas. Si va a implementar varios sitios, debe recopilar esta información para cada uno de ellos.

Según los requisitos de red (por ejemplo, si hay disponible un conjunto limitado de subredes), puede optar por asignar una sola subred para todas las interfaces de Azure Stack Edge, marcadas con un asterisco (*) en la lista siguiente.

Nota:

Los requisitos adicionales para una implementación de alta disponibilidad (HA) se enumeran en línea.

Red de administración

  • Dirección de red en notación de enrutamiento de interdominios sin clases (CIDR).
  • Puerta de enlace predeterminada.
  • Una dirección IP para el puerto de administración (puerto 2) en el dispositivo Azure Stack Edge Pro 2.
    • Alta disponibilidad: cuatro direcciones IP (dos para cada dispositivo de Azure Stack Edge).
  • Seis direcciones IP secuenciales para los nodos de clúster de Azure Kubernetes Service en Azure Stack HCI (AKS-HCI).
    • Alta disponibilidad: siete direcciones IP secuenciales.
  • Una dirección IP de servicio para acceder a las herramientas de supervisión local para la instancia de la red troncal de paquetes.

Direcciones IP adicionales para el clúster de Azure Stack Edge de dos nodos en una implementación de alta disponibilidad:

  • Una dirección IP virtual para ACS (Azure Consistency Services).
  • Una dirección IP virtual para NFS (Servicios de archivos de red).
  • Dirección de red en notación de enrutamiento de interdominios sin clases (CIDR).
  • Puerta de enlace predeterminada.
  • Una dirección IP para el puerto de administración.
    • Como parte de la configuración del dispositivo Azure Stack Edge Pro*, elija un puerto entre el 2 y el 4 como puerto de administración del dispositivo Azure Stack Edge Pro con GPU.
    • Alta disponibilidad: dos direcciones IP (una para cada dispositivo Azure Stack Edge)
  • Seis direcciones IP secuenciales para los nodos de clúster de Azure Kubernetes Service en Azure Stack HCI (AKS-HCI).
    • Alta disponibilidad: siete direcciones IP secuenciales.
  • Una dirección IP de servicio para acceder a las herramientas de supervisión local para la instancia de la red troncal de paquetes.

Direcciones IP adicionales para el clúster de Azure Stack Edge de dos nodos en una implementación de alta disponibilidad:

  • Una dirección IP virtual para ACS (Azure Consistency Services).
  • Una dirección IP virtual para NFS (Servicios de archivos de red).

Red de acceso

Necesitará una subred IP para el tráfico del plano de control y una subred IP para el tráfico del plano de usuario. Si el plano de control y el plano de usuario están en la misma VLAN (o no están etiquetados con VLAN), puede usar una sola subred IP para ambos.

  • Dirección de red en notación CIDR.
  • Puerta de enlace predeterminada.
  • Una dirección IP para la interfaz del plano de control.
    • Para 5G, esta es la interfaz N2.
    • Para 4G, esta es la interfaz S1-MME.
    • Para la combinación de 4G y 5G, esta es la interfaz N2/S1-MME.
  • Una dirección IP para la interfaz del plano de usuario.
    • Para 5G, esta es la interfaz N3.
    • Para 4G, esta es la interfaz S1-U.
    • Para la combinación de 4G y 5G, esta es la interfaz N3/S1-U.
  • Una dirección IP para el puerto 3 en el dispositivo Azure Stack Edge Pro 2.
  • Plano de control de alta disponibilidad:
    • dirección IP del enrutador de puerta de enlace.
    • dos direcciones IP (una por ASE) para usarlas como direcciones vNIC en las funciones AMF.
  • Plano de usuario de alta disponibilidad:
    • dirección IP del enrutador de puerta de enlace.
    • dos direcciones IP (una por ASE) para usarlas como direcciones vNIC en las interfaces de las funciones UPF en la subred de acceso local.
  • Dirección de red en notación CIDR.
  • Puerta de enlace predeterminada.
  • Una dirección IP para la interfaz del plano de control.
    • Para 5G, esta es la interfaz N2.
    • Para 4G, esta es la interfaz S1-MME.
    • Para la combinación de 4G y 5G, esta es la interfaz N2/S1-MME.
  • Una dirección IP para la interfaz del plano de usuario.
    • Para 5G, esta es la interfaz N3.
    • Para 4G, esta es la interfaz S1-U.
    • Para la combinación de 4G y 5G, esta es la interfaz N3/S1-U.
  • Una dirección IP para el puerto 5 en el dispositivo Azure Stack Edge Pro.
  • Plano de control de alta disponibilidad:
    • dirección IP del enrutador de puerta de enlace.
    • dos direcciones IP (una por ASE) para usarlas como direcciones vNIC en las funciones AMF.
  • Plano de usuario de alta disponibilidad:
    • dirección IP del enrutador de puerta de enlace.
    • dos direcciones IP (una por ASE) para usarlas como direcciones vNIC en las interfaces de las funciones UPF en la subred de acceso local.

Redes de datos

Asigne las siguientes direcciones IP para cada red de datos del sitio:

  • Dirección de red en notación CIDR.
  • Puerta de enlace predeterminada.
  • Una dirección IP para la interfaz del plano de usuario.
    • Para 5G, esta es la interfaz N6.
    • Para 4G, esta es la interfaz SGi.
    • Para la combinación de 4G y 5G, esta es la interfaz N6/SGi.

Todas las redes de datos del sitio deben compartir las siguientes direcciones IP:

  • Una dirección IP para todas las redes de datos del puerto 3 en el dispositivo Azure Stack Edge Pro 2.
  • Una dirección IP para todas las redes de datos del puerto 4 en el dispositivo Azure Stack Edge Pro 2.
  • Alta disponibilidad: dirección IP del enrutador de puerta de enlace.
  • Alta disponibilidad: dos direcciones IP (una por ASE) para usarlas como direcciones vNIC en las interfaces de las UPF a la red de datos.
  • Una dirección IP para todas las redes de datos del puerto 5 en el dispositivo Azure Stack Edge Pro con GPU.
  • Una dirección IP para todas las redes de datos del puerto 6 del dispositivo Azure Stack Edge Pro con GPU.
  • Alta disponibilidad: dirección IP del enrutador de puerta de enlace.
  • Alta disponibilidad: dos direcciones IP (una por ASE) para usarlas como direcciones vNIC en las interfaces de las UPF a la red de datos.

Direcciones IP virtuales adicionales (solo alta disponibilidad)

Las siguientes direcciones IP virtuales son necesarias para una implementación de alta disponibilidad. Estas direcciones IP NO DEBEN estar en ninguna de las subredes del plano de control o del plano de usuario; se usan como destinos de rutas estáticas en los enrutadores de puerta de enlace de red de acceso. Es decir, pueden ser cualquier dirección IP válida que no esté incluida en ninguna de las subredes configuradas en la red de acceso.

  • Una dirección virtual que se usará como dirección N2 virtual. El equipo RAN está configurado para usar esta dirección.
  • Una dirección virtual que se usará como punto de conexión de túnel virtual en el punto de referencia N3.

VLAN

Opcionalmente, puede configurar el dispositivo Azure Stack Edge Pro con etiquetas de red de área local virtual (VLAN). Puede usar esta configuración para habilitar la separación del tráfico de nivel 2 en las interfaces N2, N3 y N6, o sus equivalentes 4G. Por ejemplo, el dispositivo ASE tiene un único puerto para el tráfico N2 y N3 y un único puerto para todo el tráfico de red de datos. Puede usar etiquetas VLAN para separar el tráfico N2 y N3, o para separar el tráfico de cada red de datos conectada.

Asigne identificadores de VLAN para cada red según sea necesario.

Si usa redes VLAN para separar el tráfico de cada red de datos, se requiere una subred local para los puertos orientados a la red de datos que cubren la VLAN predeterminada (VLAN 0). Si se desea alta disponibilidad, debe asignar la dirección IP del enrutador de puerta de enlace dentro de esta subred.

Asignación de grupos de direcciones IP del equipo de usuario (UE)

Azure Private 5G Core admite los siguientes métodos de asignación de direcciones IP para las UE.

  • Dinámica. La asignación de direcciones IP dinámicas asigna automáticamente una nueva dirección IP a una UE cada vez que se conecta a la red móvil privada.

  • Estática. La asignación de direcciones IP estáticas garantiza que una UE recibe la misma dirección IP cada vez que se conecta a la red móvil privada. Las direcciones IP estáticas son útiles cuando se desea que las aplicaciones de Internet de las cosas (IoT) puedan conectarse de forma coherente al mismo dispositivo. Por ejemplo, puede configurar una aplicación de análisis de vídeo con las direcciones IP de las cámaras que proporcionan secuencias de vídeo. Si estas cámaras tienen direcciones IP estáticas, no tendrá que volver a configurar la aplicación de análisis de vídeo con nuevas direcciones IP cada vez que se reinicien las cámaras. Deberá asignar direcciones IP estáticas a una UE como parte del aprovisionamiento de su SIM.

Puede optar por admitir uno o ambos de estos métodos para cada red de datos del sitio.

Para cada red de datos que va a implementar:

  • Decida qué métodos de asignación de direcciones IP desea admitir.

  • Para cada método que quiera admitir, identifique un grupo de direcciones IP desde el que se puedan asignar direcciones IP a las UE. Debe proporcionar cada grupo de direcciones IP en notación CIDR.

    Si decide admitir ambos métodos para una red de datos determinada, asegúrese de que los grupos de direcciones IP tienen el mismo tamaño y no se superponen.

  • Decida si desea habilitar la dirección de red y la traducción de puertos (NAPT) para la red de datos. NAPT permite convertir un gran grupo de direcciones IP privadas de equipos de usuario en un número reducido de direcciones IP públicas. La traducción se realiza en el punto donde entra el tráfico a la red de datos, de modo que se maximiza la utilidad de un suministro limitado de direcciones IP públicas.

Configurar servidores del Sistema de nombres de dominio (DNS)

Importante

Si no configura servidores DNS para una red de datos, todos los equipos de usuario que usan esa red no podrán resolver los nombres de dominio.

DNS permite la traducción entre nombres de dominio legibles por personas y sus direcciones IP legibles por máquina asociadas. En función de sus requisitos, tiene las siguientes opciones para configurar un servidor DNS para la red de datos:

  • Si necesita que los equipos de usuario conectadas a esta red de datos resuelvan los nombres de dominio, debe configurar uno o varios servidores DNS. Debe usar un servidor DNS privado si necesita la resolución DNS de nombres de host internos. Si solo proporciona acceso a Internet a nombres DNS públicos, puede usar un servidor DNS público o privado.
  • Si no necesita que los equipos de usuario realicen la resolución DNS o si todos los equipos de usuario de la red usarán sus propios servidores DNS configurados localmente (en lugar de los servidores DNS señalados por el núcleo de paquetes), puede omitir esta configuración.

Configurar

Preparación de las redes

Para cada sitio que vaya a implementar:

  • Asegúrese de que tiene al menos un conmutador de red con al menos tres puertos disponibles. Conectará cada dispositivo de Azure Stack Edge Pro al conmutador en el mismo sitio como parte de las instrucciones de Pedido y configuración de los dispositivos de Azure Stack Edge Pro.
  • En cada red en la que decida no habilitar NAPT (como se describe en el apartado Asignación de grupos de direcciones IP del equipo de usuario (UE)), configure la red de datos para enrutar el tráfico destinado a los grupos de direcciones IP del equipo de usuario a través de la dirección IP asignada para la interfaz del plano de usuario de la instancia de la red troncal de paquetes de la red de datos.

Configuración de puertos para el acceso local

La tabla siguiente contiene los puertos que debe abrir para el acceso local de Azure Private 5G Core. Esto incluye el acceso de administración local y la señalización del plano de control.

Debe configurar estos además de los puertos necesarios para Azure Stack Edge (ASE).

Azure Private 5G Core

Port Interfaz de ASE Descripción
TCP 443 Inbound Administración (LAN) Acceso a las herramientas de supervisión local (paneles principales de paquetes y seguimiento distribuido).
5671 Entrada y salida Administración (LAN) Comunicación con Azure Event Hubs, protocolo AMQP
5672 Entrada y salida Administración (LAN) Comunicación con Azure Event Hubs, protocolo AMQP
UDP 1812 entrada y salida Administración (LAN) Autenticación con un servidor AAA RADIUS.
Solo es necesario cuando RADIUS está en uso.
SCTP 38412 Inbound Puerto 3 (red de acceso) Señalización de acceso del plano de control (interfaz N2).
Solo es necesario para las implementaciones 5G.
SCTP 36412 Inbound Puerto 3 (red de acceso) Señalización de acceso del plano de control (interfaz S1-MME).
Solo es necesario para las implementaciones 4G.
UDP 2152 In/Outbound Puerto 3 (red de acceso) Acceda a los datos del plano de usuario de red (interfaz N3 para 5G, S1-U para 4G o N3/S1-U para la combinación de 4G y 5G).
Todo el tráfico de IP Puertos 3 y 4 (redes de datos) Datos del plano de usuario de la red de datos (interfaz N6 para 5G, SGi para 4G o N6/SGi para la combinación de 4G y 5G).
Solo es necesario en el puerto 3 si hay redes de datos configuradas en ese puerto.

La tabla siguiente contiene los puertos que debe abrir para el acceso local de Azure Private 5G Core. Esto incluye el acceso de administración local y la señalización del plano de control.

Debe configurar estos además de los puertos necesarios para Azure Stack Edge (ASE).

Azure Private 5G Core

Port Interfaz de ASE Descripción
TCP 443 Inbound Administración (LAN) Acceso a las herramientas de supervisión local (paneles principales de paquetes y seguimiento distribuido).
5671 Entrada y salida Administración (LAN) Comunicación con Azure Event Hubs, protocolo AMQP
5672 Entrada y salida Administración (LAN) Comunicación con Azure Event Hubs, protocolo AMQP
UDP 1812 entrada y salida Administración (LAN) Autenticación con un servidor AAA RADIUS.
Solo es necesario cuando RADIUS está en uso.
SCTP 38412 Inbound Puerto 5 (red de acceso) Señalización de acceso del plano de control (interfaz N2).
Solo es necesario para las implementaciones 5G.
SCTP 36412 Inbound Puerto 5 (red de acceso) Señalización de acceso del plano de control (interfaz S1-MME).
Solo es necesario para las implementaciones 4G.
UDP 2152 In/Outbound Puerto 5 (red de acceso) Acceda a los datos del plano de usuario de red (interfaz N3 para 5G, S1-U para 4G o N3/S1-U para la combinación de 4G y 5G).
Todo el tráfico de IP Puertos 5 y 6 (redes de datos) Datos del plano de usuario de la red de datos (interfaz N6 para 5G, SGi para 4G o N6/SGi para la combinación de 4G y 5G).
Solo es necesario en el puerto 5 si hay redes de datos configuradas en ese puerto.

Requisitos de los puertos de Azure Stack Edge

N.º de puerto Entrada o salida Ámbito del puerto Obligatorio Notas
UDP 123 (NTP) Fuera WAN En algunos casos. Este puerto solo es necesario si va a usar un servidor NTP local o un servidor basado en Internet para ASE.
UDP 53 (DNS) Fuera WAN En algunos casos. Consulte Configuración de servidores del Sistema de nombres de dominio (DNS).
TCP 5985 (WinRM) Salida/Entrada LAN Sí Necesario para que WinRM conecte ASE a través de PowerShell durante la implementación de AP5GC.
Consulte Comisión de un clúster de AKS.
TCP 5986 (WinRM) Salida/Entrada LAN Sí Necesario para que WinRM conecte ASE a través de PowerShell durante la implementación de AP5GC.
Consulte Comisión de un clúster de AKS.
UDP 67 (DHCP) Fuera LAN Sí
TCP 445 (SMB) In LAN No ASE para AP5GC no requiere un servidor de archivos local.
TCP 2049 (NFS) In LAN No ASE para AP5GC no requiere un servidor de archivos local.

Requisitos de puertos para IoT Edge

N.º de puerto Entrada o salida Ámbito del puerto Obligatorio Notas
TCP 443 (HTTPS) Fuera WAN No Esta configuración solo es necesaria cuando se usan scripts manuales o Device Provisioning Service (DPS) de Azure IoT.

Requisitos de puerto para Kubernetes en Azure Stack Edge

N.º de puerto Entrada o salida Ámbito del puerto Obligatorio Notas
TCP 31000 (HTTPS) In LAN Sí Necesario para que el panel de Kubernetes supervise el dispositivo.
TCP 6443 (HTTPS) In LAN Sí Necesario para el acceso con kubectl.

Puertos de firewall de salida necesarios

Revise y aplique las recomendaciones de firewall para los siguientes servicios:

La tabla siguiente contiene los patrones de dirección URL para el tráfico saliente de Azure Private 5G Core.

Patrón de URL Descripción
https://*.azurecr.io Necesario para extraer imágenes de contenedor para cargas de trabajo de Azure Private 5G Core.
https://*.microsoftmetrics.com
https://*.hot.ingestion.msftcloudes.com		 Necesario para la supervisión y la telemetría del servicio Azure Private 5G Core.

Registro de proveedores de recursos

Para usar Azure Private 5G Core, debe registrar algunos proveedores de recursos adicionales en su suscripción de Azure.

Sugerencia

Si no tiene instalada la CLI de Azure, consulte las instrucciones de que se indican en Instalación de la CLI de Azure. Como alternativa, puede usar Azure Cloud Shell en el portal.

  1. Inicie sesión en la CLI de Azure con una cuenta de usuario asociada al inquilino de Azure en el que vaya a implementar Azure Private 5G Core en:

    az login

    Sugerencia

    Consulte Inicio de sesión de forma interactiva para obtener instrucciones completas.

  2. Si la cuenta tiene varias suscripciones, asegúrese de que está en la correcta:

    az account set --subscription <subscription_id>

  3. Compruebe la versión de la CLI de Azure:

    az version

    Si la versión de la CLI es inferior a la 2.37.0, debe actualizarla a una versión más reciente. Consulte Actualización de la CLI de Azure.

  4. Registre los proveedores de recursos siguientes:

    az provider register --namespace Microsoft.MobileNetwork
az provider register --namespace Microsoft.HybridNetwork
az provider register --namespace Microsoft.ExtendedLocation
az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration

Recuperación del identificador de objeto (OID)

Debe obtener el identificador de objeto (OID) del proveedor de recursos de ubicación personalizado del inquilino de Azure. Debe proporcionar este OID al crear el servicio Kubernetes. Puede obtener el OID mediante la CLI de Azure o Azure Cloud Shell en el portal. Debe ser propietario de la suscripción de Azure.

  1. Inicie sesión en la CLI de Azure o en Azure Cloud Shell.

  2. Recupere el OID:

    az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query id -o tsv

Este comando consulta la ubicación personalizada y genera una cadena OID. Guarde esta cadena para usarla más adelante al realizar la puesta en marcha del dispositivo Azure Stack Edge.

Pedido y configuración de dispositivos Azure Stack Edge Pro

Para cada sitio que quiera agregar a la red móvil privada, debe hacer lo siguiente. Las instrucciones detalladas sobre cómo llevar a cabo cada paso se incluyen en la columna Instrucciones detalladas, si procede.

N.º de paso Descripción Instrucciones detalladas
1. Complete la lista de comprobación de implementación de Azure Stack Edge Pro 2. Lista de comprobación de implementación de un dispositivo Azure Stack Edge Pro 2
2. Pida y prepare el dispositivo Azure Stack Edge Pro 2. Tutorial: Preparación de la implementación de Azure Stack Edge Pro 2
3. Acople y conecte el dispositivo Azure Stack Edge Pro 2.

Al llevar a cabo este procedimiento, debe asegurarse de que los puertos del dispositivo estén conectados de la siguiente manera:

- Puerto 2: administración
- Puerto 3: red de acceso (y, opcionalmente, redes de datos)
- Puerto 4: redes de datos		 Tutorial: Instalación de Azure Stack Edge Pro 2
4. Conéctese al dispositivo Azure Stack Edge Pro 2 mediante la interfaz de usuario web local. Tutorial: Conexión a Azure Stack Edge Pro 2
5. Configure la red para el dispositivo Azure Stack Edge Pro 2.

Nota: Cuando se usa un ASE en un servicio Azure Private 5G Core, se usa el puerto 2 para la administración en lugar de para los datos. En el tutorial vinculado se da por supuesto un ASE genérico que usa el puerto 2 para los datos.

Si RAN y Packet Core están en la misma subred, no es necesario configurar una puerta de enlace para el puerto 3 o el puerto 4.

Además, puede configurar opcionalmente el dispositivo Azure Stack Edge Pro para que se ejecute detrás de un proxy web.

Compruebe que las conexiones salientes del dispositivo Azure Stack Edge Pro a los puntos de conexión de Azure Arc están abiertas.

No configure conmutadores virtuales, redes virtuales ni direcciones IP de proceso.		 Tutorial: Configuración de la red para Azure Stack Edge Pro 2

(Opcionalmente) Configuración del proxy web para Azure Stack Edge Pro

Requisitos de red de Azure Arc

Requisitos de red del agente de Azure Arc
6. Establezca un nombre, un nombre de DNS y, opcionalmente, una configuración horaria.

No configure una actualización.		 Tutorial: Configuración de los valores del dispositivo para Azure Stack Edge Pro 2
7. Configure certificados y configure el cifrado en reposo para el dispositivo Azure Stack Edge Pro 2. Después de cambiar los certificados, es posible que tenga que volver a abrir la interfaz de usuario local en una nueva ventana del explorador para evitar que los certificados almacenados en caché antiguos causen problemas. Tutorial: Configuración de certificados para un dispositivo Azure Stack Edge Pro 2
8. Active el dispositivo Azure Stack Edge Pro 2.

No siga la sección para implementar las cargas de trabajo.		 Tutorial: Activación de Azure Stack Edge Pro 2
9. Habilite la administración de máquinas virtuales en Azure Portal.

Al habilitar esta opción inmediatamente después de activar el dispositivo Azure Stack Edge Pro 2, en ocasiones se produce un error. Espere un minuto y vuelva a intentarlo.		 Vaya al recurso ASE en Azure Portal, vaya a Servicios perimetrales, seleccione Máquinas virtuales y elija Habilitar.
10. Ejecute las pruebas de diagnóstico para el dispositivo Azure Stack Edge Pro 2 en la interfaz de usuario web local y compruebe si se superan todas.

Es posible que vea una advertencia sobre un puerto desconectado y sin usar. Si la advertencia está relacionada con cualquiera de estos puertos:

- Puerto 2: administración
- Puerto 3: red de acceso (y, opcionalmente, redes de datos)
- Puerto 4: redes de datos

, debe corregir el problema. Para todos los demás puertos, puede omitir la advertencia.

Si hay algún error, resuélvalo antes de continuar con los pasos restantes. Esto incluye los errores relacionados con puertas de enlace no válidas en puertos sin usar. En este caso, elimine la dirección IP de la puerta de enlace o establézcala en una puerta de enlace válida para la subred.		 Ejecución de diagnósticos y recopilación de registros para solucionar problemas de dispositivos Azure Stack Edge

Importante

Debe asegurarse de que el dispositivo Azure Stack Edge Pro 2 sea compatible con la versión de Azure Private 5G Core que planea instalar. Consulte Compatibilidad entre Packet Core y Azure Stack Edge (ASE). Si necesita actualizar el dispositivo Azure Stack Edge Pro 2, consulte Actualización del dispositivo Azure Stack Edge Pro 2.

N.º de paso Descripción Instrucciones detalladas
1. Complete la lista de comprobación de implementación de Azure Stack Edge Pro con GPU. Lista de comprobación para implementación de un dispositivo Azure Stack Edge Pro con GPU
2. Pida y prepare el dispositivo Azure Stack Edge Pro con GPU. Tutorial: Preparación de la implementación de Azure Stack Edge Pro con GPU
3. Acople y conecte el dispositivo Azure Stack Edge Pro con GPU.

Al llevar a cabo este procedimiento, debe asegurarse de que el dispositivo tenga los puertos conectados de la siguiente manera:

- Puerto 5: red de acceso
- Puerto 6: redes de datos

Además, debe tener un puerto conectado a la red de administración. Puede elegir cualquier puerto del 2 al 4.		 Tutorial: Instalación de Azure Stack Edge Pro con GPU
4. Conéctese al dispositivo Azure Stack Edge Pro con GPU mediante la interfaz de usuario web local. Tutorial: Conexión a Azure Stack Edge Pro con GPU
5. Configure la red para el dispositivo Azure Stack Edge Pro con GPU. Siga las instrucciones correspondientes a un dispositivo de un solo nodo si es una implementación estándar o de un clúster de dos nodos si es una implementación de alta disponibilidad.

Nota: Cuando se usa un ASE en un servicio Azure Private 5G Core, se usa el puerto 2 para la administración en lugar de para los datos. En el tutorial vinculado se da por supuesto un ASE genérico que usa el puerto 2 para los datos.

Si el RAN y Packet Core están en la misma subred, no es necesario configurar una puerta de enlace para el puerto 5 o el puerto 6.

Además, puede configurar opcionalmente el dispositivo Azure Stack Edge Pro con GPU para que se ejecute detrás de un proxy web.

Compruebe que las conexiones salientes del dispositivo Azure Stack Edge Pro con GPU a los puntos de conexión de Azure Arc están abiertas.

No configure conmutadores virtuales, redes virtuales ni direcciones IP de proceso.		 Tutorial: Configuración de la red para Azure Stack Edge Pro con GPU

(Opcionalmente) Configuración del proxy web para Azure Stack Edge Pro

Requisitos de red de Azure Arc

Requisitos de red del agente de Azure Arc
6. Establezca un nombre, un nombre de DNS y, opcionalmente, una configuración horaria.

No configure una actualización.		 Tutorial: Configuración de los valores del dispositivo para Azure Stack Edge Pro con GPU
7. Configure los certificados para el dispositivo Azure Stack Edge Pro con GPU. Después de cambiar los certificados, es posible que tenga que volver a abrir la interfaz de usuario local en una nueva ventana del explorador para evitar que los certificados almacenados en caché antiguos causen problemas. Tutorial: Configuración de certificados para Azure Stack Edge Pro con GPU
8. Active el dispositivo Azure Stack Edge Pro con GPU.

No siga la sección para implementar las cargas de trabajo.		 Tutorial: Activación de Azure Stack Edge Pro con GPU
9. Habilite la administración de máquinas virtuales en Azure Portal.

Al habilitar esta opción inmediatamente después de activar el dispositivo Azure Stack Edge Pro 2, en ocasiones se produce un error. Espere un minuto y vuelva a intentarlo.		 Vaya al recurso ASE en Azure Portal, vaya a Servicios perimetrales, seleccione Máquinas virtuales y elija Habilitar.
10. Ejecute las pruebas de diagnóstico para el dispositivo Azure Stack Edge Pro con GPU en la interfaz de usuario web local y compruebe si se superan todas.

Es posible que vea una advertencia sobre un puerto desconectado y sin usar. Debe corregir el problema si la advertencia está relacionada con cualquiera de estos puertos:

- Puerto 5.
- Puerto 6.
- El puerto que eligió para conectarse a la red de administración en el tercer paso.

Para todos los demás puertos, puede omitir la advertencia.

Si hay algún error, resuélvalo antes de continuar con los pasos restantes. Esto incluye los errores relacionados con puertas de enlace no válidas en puertos sin usar. En este caso, elimine la dirección IP de la puerta de enlace o establézcala en una puerta de enlace válida para la subred.		 Ejecución de diagnósticos y recopilación de registros para solucionar problemas de dispositivos Azure Stack Edge

Importante

Debe asegurarse de que el dispositivo Azure Stack Edge Pro con GPU sea compatible con la versión de Azure Private 5G Core que planea instalar. Consulte Compatibilidad entre Packet Core y Azure Stack Edge (ASE). Si necesita actualizar el dispositivo Azure Stack Edge Pro con GPU, consulte Actualización de Azure Stack Edge Pro con GPU.

Pasos siguientes

Ahora puede poner en marcha el clúster de Azure Kubernetes Service (AKS) en el dispositivo Azure Stack Edge Pro 2 o Azure Stack Edge Pro con GPU para tenerlo preparado para implementar Azure Private 5G Core.