Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describe el proceso de migración de la puerta de enlace de ExpressRoute, lo que le permite pasar de la SKU actual a cualquier SKU igual o superior y de ip básica a IP estándar, lo que mejora la confiabilidad y la disponibilidad, mientras que no se admiten las degradaciones.
Para obtener instrucciones sobre cómo actualizar direcciones IP públicas de SKU básicas para otros servicios de red, consulte Actualización de la SKU básica a estándar.
Important
El 30 de septiembre de 2025 se retirarán las direcciones IP públicas del SKU Básico. Para obtener más información, consulte el anuncio oficial. Si actualmente usa direcciones IP públicas de SKU básicas, asegúrese de actualizar a direcciones IP públicas de SKU estándar antes de la fecha de retirada.
Experiencia de migración de puerta de enlace
La experiencia de migración de puerta de enlace le permite implementar una segunda puerta de enlace de red virtual en la misma gatewaySubnet, con Azure asignando automáticamente una nueva dirección IP pública, lo que elimina la necesidad de crear direcciones IP manuales, mientras que las configuraciones se migran de la puerta de enlace antigua a la nueva; Ambas puertas de enlace se ejecutan simultáneamente para minimizar la interrupción, aunque pueden producirse interrupciones breves de conectividad.
Después de la migración, la puerta de enlace antigua y sus conexiones se eliminan y la nueva puerta de enlace se etiqueta con CreatedBy: GatewaySKUMigration para identificarla como un recurso migrado y no debe eliminarse.
Escenarios de migración admitidos
La experiencia guiada de migración de puerta de enlace de ExpressRoute permite a los clientes pasar de su SKU actual a cualquier SKU igual o superior. No se admite la migración a una SKU inferior (reducciones).
Si tiene una puerta de enlace de ExpressRoute implementada en la misma red virtual que vpn Gateway, puede usar la herramienta de migración de puerta de enlace de ExpressRoute. No hay ningún impacto esperado en el tráfico de VPN Gateway durante este proceso.
Aprenda a migrar mediante Azure Portal.
Aprenda a migrar mediante PowerShell.
Para mejorar la confiabilidad y la alta disponibilidad, se recomienda migrar a una SKU habilitada para Az.
Migración a ErGwScale (puerta de enlace escalable)
La puerta de enlace escalable de ExpressRoute (ErGwScale) es una nueva SKU de puerta de enlace de red virtual que proporciona conectividad flexible y de alto ancho de banda para las redes virtuales de Azure.
Important
La unidad de escalado mínima debe ser 1, cuando la unidad de escalado máxima es 1.
Puede configurar el escalado de la puerta de enlace, según los requisitos, estableciendo las unidades de escalado mínimas y máximas:
- Para configurar una puerta de enlace de tamaño fijo, establezca las unidades de escalado mínima y máxima en el mismo valor (por ejemplo, establezca ambas en 1, establezca ambas en 20, establezca ambas en 40).
- Para habilitar el escalado automático, establezca la unidad de escalado mínima en 2 o superior y especifique la unidad de escalado máxima deseada (hasta 40).
Esto permite que la puerta de enlace se escale automáticamente en función de los requisitos de la carga de trabajo.
Para más información, consulte Acerca de la puerta de enlace escalable.
| Scenario | Unidad de escala mínima | Unidad de escala máxima | ¿Está habilitado el escalado automático? |
|---|---|---|---|
| Escalado fijo | 1 | 1 | No |
| Escalado fijo | 20 | 20 | No |
| Escalado fijo | 40 | 40 | No |
| Autoscaling | 2 o más | Hasta 40 | Sí |
Pasos para migrar a una nueva puerta de enlace
- Validar: compruebe que todos los recursos están en un estado correcto. Si no se cumplen los requisitos previos, no se puede realizar la validación y no se puede continuar con la migración.
- Preparación: Azure crea una nueva puerta de enlace de red virtual, asigna automáticamente una nueva dirección IP pública, una nueva dirección IP pública y vuelve a establecer conexiones; este proceso puede tardar hasta 45 minutos; Puede especificar un nombre personalizado para la nueva puerta de enlace o Azure agregará _migrated al nombre original de forma predeterminada. Durante la preparación, la puerta de enlace existente está bloqueada para evitar cambios, con la opción de anular y eliminar la nueva puerta de enlace y conexiones.
Note
La nueva puerta de enlace se crea en la misma región que la existente. Para cambiar las regiones, debe eliminar la puerta de enlace actual y crear una nueva en la región deseada.
- Migrar: Cambiar el tráfico de la puerta de enlace antigua a la nueva. Este paso puede tardar hasta 15 minutos y puede provocar interrupciones breves de conectividad. No salgas de la página de migración mientras se mueve el tráfico. Dejar la página puede interrumpir el proceso.
- Confirmación: finalice la migración eliminando la puerta de enlace original y sus conexiones. Si necesita cancelar la migración, cambie primero el tráfico a la puerta de enlace original seleccionando el botón de radio de la sección Migrar , haga clic en Migrar y, por último, elija Anular para eliminar la nueva puerta de enlace y sus conexiones.
Important
Después de la migración, valide la conectividad para asegurarse de que todo funciona según lo previsto. Puede revertir a la puerta de enlace anterior seleccionando Anular después del paso de preparación, lo que eliminará la nueva puerta de enlace y las conexiones.
Limitations
La experiencia de migración de puerta de enlace guiada tiene las siguientes limitaciones:
- Solo ExpressRoute: la herramienta de migración está diseñada para puertasde enlace de red virtual de ExpressRoute. No admite puertas de enlace de VPN ni otros tipos de puerta de enlace. - Mismo requisito de red virtual: la migración solo se admite dentro de la misma red virtual. No se admiten migraciones entre suscripciones, entre regiones o tipos de puerta de enlace (por ejemplo, hacia o desde puertas de enlace de VPN).
- Sin degradaciones: no se admite la degradación de una SKU habilitada para Az a una SKU no habilitada para Az.
- Tamaño de GatewaySubnet: GatewaySubnet debe tener un prefijo /27 o más para continuar con la migración. Para obtener más información, consulte Creación de varios prefijos para una subred para obtener más información.
- Conectividad de puntos de conexión privados: los puntos de conexión privados (PE) conectados a través del emparejamiento privado de ExpressRoute podrían experimentar problemas de conectividad durante la migración. Consulte las instrucciones sobre cómo mitigar estos problemas en la documentación de conectividad del punto de conexión privado. Conectividad de punto de conexión privado.
- Puertas de enlace heredadas: no se admiten puertas de enlace de ExpressRoute creadas o conectadas a circuitos en 2017 o versiones anteriores .
- SKU no admitidas: las puertas de enlace que usan la SKU "predeterminada" no son aptas para la migración. Para comprobar la idoneidad de la migración de la puerta de enlace, debe haber una notificación de Advisor.
- Circuito dedicado incompatible: la migración de puerta de enlace no puede continuar con un módulo de seguridad de hardware (HSM) dedicado conectado a la red virtual. Para continuar con la migración, desasigne el módulo de seguridad de hardware (HSM) dedicado. Para ver los pasos de solución de problemas detallados, consulte Solución de problemas de HSM dedicado.
Para obtener información detallada sobre cómo solucionar errores y procedimientos recomendados, consulte Solución de problemas de migración de puerta de enlace.
FAQ
¿Cómo se agrega un segundo prefijo a GatewaySubnet?
La adición de varios prefijos a GatewaySubnet se encuentra actualmente en versión preliminar pública y solo se admite a través de PowerShell. Al agregar un prefijo adicional, la puerta de enlace migrada usará ambos prefijos, por lo que no elimine el prefijo anterior. Para obtener instrucciones, consulte Creación de varios prefijos para una subred.
¿Cómo se supervisa el estado de la nueva puerta de enlace?
La supervisión de la nueva puerta de enlace es la misma que para la puerta de enlace anterior. La nueva puerta de enlace es un recurso independiente con sus propias métricas. Durante la migración, también puede observar patrones de tráfico mediante la herramienta de migración.
Después de la migración, si tenía configurada la supervisión, las alertas, las ventanas de mantenimiento definidas por el cliente o la configuración de diagnóstico, deberá volver a configurarlas en la puerta de enlace recién creada.
¿La migración provocará tiempo de inactividad?
La migración puede provocar unos minutos de tiempo de inactividad. Planee realizar la migración durante una ventana de mantenimiento para minimizar el impacto.
¿Cuánto tiempo puedo esperar antes de confirmar la nueva puerta de enlace?
No hay un período de espera obligatorio para realizar la confirmación. Sin embargo, si necesita tiempo para validar la conectividad y asegurarse de que se cumplen todos los requisitos antes de finalizar la migración, tendrá hasta 15 días para confirmar después de la migración.
¿Cómo puedo comprobar si mi SKU de puerta de enlace es apta para la migración?
Azure Advisor le notificará si la puerta de enlace es apta o requiere la migración. También puede comprobar el recurso de puerta de enlace de ExpressRoute en el portal de Azure; si la puerta de enlace es apta, un banner en la parte superior de la página mostrará el mensaje "Implementar puertas de enlace de ExpressRoute de zona redundante".
¿Cómo puedo comprobar si mi puerta de enlace es resistente a fallos de zona después de la migración?
Para confirmar que el gateway es resistente a fallos de zona después de la migración:
- Compruebe Azure Advisor: si la puerta de enlace es resistente a la zona, ya no verá alertas de Advisor que recomiendan una puerta de enlace con redundancia de zona.
- Comprobar etiquetas de recursos: la puerta de enlace migrada tendrá una etiqueta predeterminada etiquetada
GatewaySKUMigration, lo que indica que se ha movido al modelo de implementación resistente a la zona.
Estas comprobaciones confirman que tu puerta de enlace es ahora resiliente a zonas.
¿Puedo revertir este cambio?
Sí, hasta que se confirme. La migración se compone de cuatro pasos principales:
Validar: confirma si la puerta de enlace es apta para la migración. No hay cambios en esta fase; nada que revertir
Preparar: crea una nueva puerta de enlace de red virtual con la configuración deseada. El proceso se puede anular después del paso 2 y se eliminará la nueva puerta de enlace.
Migración: transfiera la configuración de la puerta de enlace existente a la nueva. Si es necesario, la configuración se puede revertir a la puerta de enlace existente después del paso 3. No navegue desde la página de migración mientras se mueve el tráfico. Dejar la página puede interrumpir el proceso.
Comprometerse: finalizar la migración desmantelando la antigua puerta de enlace y sus conexiones. Una vez confirmado el cambio, ya no se puede revertir.
¿Cuál es el impacto del tráfico durante la migración? ¿Hay alguna interrupción del enrutamiento o pérdida de paquetes?
Durante el proceso de migración, el tráfico se redirige sin problemas. No hay ninguna pérdida de paquetes esperada ni interrupción del enrutamiento en condiciones normales.
¿Qué debo hacer si se produce un error en el paso de preparación debido a una conexión entre regiones en un circuito de SKU básico durante la migración de la puerta de enlace?
Si se produce un error en el paso de preparación porque el circuito de SKU básico tiene una conexión entre regiones, anule la migración de la puerta de enlace y actualice la SKU del circuito antes de intentarlo de nuevo. Esta configuración no es compatible y la migración continúa produciendo un error hasta que se actualice la SKU del circuito.
Pasos siguientes
- Solución de problemas de migración con Solución de problemas de migración de puerta de enlace.
- Aprenda a migrar mediante Azure Portal.
- Aprenda a migrar mediante PowerShell.