Acceso a Microsoft Azure

Oracle y Microsoft han creado una conexión entre varios sistemas en la nube entre Oracle Cloud Infrastructure y Microsoft Azure en determinadas regiones. Esta conexión permite configurar cargas de trabajo en varias nubes sin el tráfico que se produce entre ellas al gestionarlo mediante internet. Este tema describe cómo configurar recursos de infraestructura de redes virtuales para activar este tipo de despliegue entre nubes.

Para obtener información sobre los despliegues de Oracle Database multinube que utilizan Oracle Cloud Infrastructure y Microsoft Azure, consulte Oracle Database@Azure. Este servicio aloja bases de datos de Oracle Exadata en centros de datos de Azure para la latencia más baja posible.

Aspectos destacados

  • Puede conectar una red virtual de Microsoft Azure (VNet) a una red virtual en la nube (VCN) de Oracle Cloud Infrastructure (OCI) y ejecutar una carga de trabajo entre varias nubes. En el caso de uso típico, puede desplegar Oracle Database en OCI y desplegar una instancia de Oracle, .NET o una aplicación personalizada en Microsoft Azure.
  • Las dos redes virtuales deben pertenecer a la misma compañía y no deben tener CIDR solapados. La conexión requiere que cree un circuito de Azure ExpressRoute y un circuito virtual de OCI FastConnect.

Disponibilidad

La conexión entre nubes entre OCI y Azure solo está disponible en las regiones y las ubicaciones de ExpressRoute que se indican a continuación. Para obtener más información sobre las ubicaciones de regiones de Azure y sobre Azure ExpressRoute, consulte ExpressRoute peering locations and conectividad partners en la documentación de Azure.

En la siguiente imagen se muestran las regiones con interconexión.

Mapa que muestra las regiones que se interconectan con Azure ExpressRoute.

Asia Pacífico (APAC)

Ubicación de OCI: clave Ubicación de Azure ExpressRoute Logotipo de Microsoft
Este de Japón (Tokio) - NRT Tokio
Singapur (Singapur) - SIN Singapur
Centro de Corea del Sur (Seúl) - ICN Seúl

Europa, Oriente Medio, África (EMEA)

Ubicación de OCI Ubicación de Azure ExpressRoute Logotipo de Microsoft
Centro de Alemania (Fráncfort) - FRA Fráncfort y Fráncfort2
Noroeste de Países Bajos (Ámsterdam) - AMS Ámsterdam2
Sur de Reino Unido (Londres) - LHR Londres
Centro de Sudáfrica (Johannesburgo) - JNB Johannesburgo

Latinoamérica (LATAM)

Ubicación de OCI Ubicación de Azure ExpressRoute Logotipo de Microsoft
Sureste de Brasil (Vinhedo) - VCP Campinas

Norteamérica (NA)

Ubicación de OCI Ubicación de Azure ExpressRoute Logotipo de Microsoft
Sureste de Canadá (Toronto) - YYZ Toronto y Toronto2
Este de EE. UU. (Ashburn) - IAD Washington DC y Washington DC2
Oeste de EE. UU. (Phoenix) - PHX Phoenix
Oeste de EE. UU. (San José) - SJC Silicon Valley

Visión general del tráfico admitido

Aquí encontrará más información sobre los tipos de tráfico admitidos.

Conexión desde la VNet hasta la VCN: extensión de una a otra

Puede conectar la VNet y la VCN de modo que el tráfico que utiliza direcciones IP privadas pase por la conexión entre nubes.

Por ejemplo, el siguiente diagrama muestra una VNet que está conectada a una VCN. Los recursos en la VNet ejecutan una aplicación .NET, que accede a una base de datos de Oracle que, a su vez, se ejecuta en los recursos del servicio de base de datos en la VCN. El tráfico entre la aplicación y la base de datos utiliza un circuito lógico que se ejecuta en la conexión entre Azure y Oracle Cloud Infrastructure.

En este diagrama muestra la conexión entre la VNet de Azure y la VCN de Oracle.

Para activar la conexión entre la VNet y la VCN, configure un circuito ExpressRoute de Azure y un circuito virtual FastConnect de Oracle Cloud Infrastructure. La conexión posee una redundancia incorporada, lo que significa que es necesario configurar un único circuito de ExpressRoute y un único circuito virtual de FastConnect. El ancho de banda para la conexión es el valor del ancho de banda que elija para el circuito de ExpressRoute.

Para obtener instrucciones, consulte Configuración de una conexión desde la VNet a la VCN.

Las VCN con intercambio de tráfico

La conexión permite que el tráfico fluya desde la VNet a través de la VCN conectada a una VCN con intercambio de tráfico en la misma región de Oracle Cloud Infrastructure o en otra diferente.

Tipos de tráfico no admitidos por la conexión

Esta conexión entre nubes no permite el tráfico entre su red local a través de VCN a la VNet, ni desde su red local a través de VNet a la VCN.

Implicaciones importantes de la conexión de nubes

En esta sección se resumen algunas implicaciones para el control de acceso, la seguridad y el rendimiento de conectar la VCN a una VNet. Por lo general, puede controlar el acceso y el tráfico mediante el uso de políticas de IAM, tablas de rutas en la VCN y reglas de seguridad en esta.

Las siguientes secciones analizan las implicaciones desde la perspectiva de la VCN. Existen implicaciones similares que afectan a VNet. Al igual que con la VCN, puede utilizar recursos de Azure, como tablas de rutas y grupos de seguridad de red, para proteger la VNet.

El control del establecimiento de una conexión

Con las políticas de Oracle Cloud Infrastructure IAM, puede controlar:

Control del flujo de tráfico a través de la conexión

Incluso si se ha establecido una conexión entre la VCN y la VNet, puede controlar el flujo de paquetes a través de la conexión con tablas de rutas de la VCN. Por ejemplo, puede restringir el tráfico únicamente a subredes específicas de la VNet.

Si no finaliza la conexión, puede detener el flujo de tráfico de la VNet al eliminar simplemente las reglas de ruta que dirigen el tráfico desde la VCN hasta la VNet. También, puede detener el tráfico de forma eficaz al eliminar cualquier regla de seguridad que active el tráfico de entrada y salida con la VNet. Esto no detiene el flujo de tráfico por la conexión, sino lo detiene en la fase de VNIC.

Control de tipos específicos de tráfico permitido

Es importante que se asegure de que todo el tráfico saliente y entrante con la VNet esté bien definido, tenga un destino o se espere en este. Implemente un grupo de seguridad de red Azure y reglas de seguridad Oracle que determinen explícitamente los tipos de tráfico que una nube puede enviar a otra y aceptar de esta.

Importante

Las instancias de Oracle Cloud Infrastructure que ejecutan imágenes de plataforma de Linux o Windows también tienen reglas de firewall que controlan el acceso a la instancia. Al solucionar problemas de acceso a una instancia, asegúrese de que todos los siguientes elementos estén configurados correctamente: los grupos de seguridad de red en los que se encuentra la instancia, las listas de seguridad asociadas a la subred de la instancia y las reglas de firewall de la instancia.

Si la instancia está ejecutando Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 u Oracle Linux Cloud Developer 8, debe usar firewalld para interactuar con las reglas de iptables. A continuación se muestran los comandos para abrir un puerto (1521 en este ejemplo):

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

Para instancias con un volumen de inicio iSCSI, el comando --reload anterior puede causar problemas. Para obtener información detallada y una solución alternativa, consulte Bloqueo del sistema de experiencias en instancias al ejecutar el firewall-cmd --reload.

Además de los firewalls y reglas de seguridad, deberá valorar otra configuración basada en el sistema operativo en las instancias de su VCN. Puede haber configuraciones por defecto que no se apliquen al propio CIDR de la VCN, pero que se apliquen involuntariamente al CIDR de la VNet.

Uso de reglas de la lista de seguridad por defecto con la VCN

Si las subredes de la VCN utilizan la lista de seguridad por defecto con las reglas por defecto, dos reglas de esa lista permiten el tráfico de entrada desde cualquier lugar (es decir, 0.0.0.0/0 y, por lo tanto, la VNet):

  • Regla de entrada con estado que permite el tráfico del puerto TCP 22 (SSH) de 0.0.0.0/0 y cualquier puerto de origen
  • Regla de entrada con estado que permite el tráfico de ICMP tipo 3 y código 4 desde 0.0.0.0/0 y cualquier puerto de origen.

Evalúe estas reglas y si desea mantenerlas o actualizarlas. Como se ha indicado anteriormente, debe asegurarse de que todo el tráfico entrante o saliente permitido esté bien definido, tenga un destino o se espere en este.

Preparación ante el impacto sobre el rendimiento y los riesgos de seguridad

Por lo general, debe preparar la VCN para las formas en que la VNet podría afectarla. Por ejemplo, la carga en la VCN o sus instancias podrían aumentar. O bien, la VCN podría experimentar un ataque malicioso directamente desde la VNet o a través de ella.

En lo que respecta al rendimiento, si la VCN proporciona un servicio a la VNet, esté preparado para ampliar el servicio y adaptarse a las demandas de la VNet. Esto puede significar que debe estar preparado para iniciar más instancias según sea necesario. O si le preocupan los altos niveles de tráfico de red que llegue a la VCN, considere utilizar reglas de seguridad sin estado para limitar el nivel de seguimiento de conexión que debe realizar VCN. Las reglas de seguridad sin estado también pueden ayudar a ralentizar el impacto de un ataque de denegación de servicio (DoS).

En cuanto a los riesgos de seguridad: si VNet está conectado a Internet, VCN puede estar expuesto a ataques de rebote. Un ataque de rebote implica un host malicioso en Internet que envía tráfico a su VCN que parece que viene de VNet. A fin de protegerse contra esto, como se ha mencionado antes, utilice las reglas de seguridad para limitar cuidadosamente el tráfico de entrante de la VNet al tráfico previsto y bien definido.

Configuración de una conexión desde la VNet hasta la VCN

En esta sección se describe cómo configurar la conexión lógica entre la VNet y la VCN (para más información, consulte Visión general del tráfico admitido).

Previos necesarios: recursos que necesita

Ya debería tener:

Aquí, como recordatorio, encontrará una tabla en la que se muestran los componentes de red equivalentes implicados en cada lado de la conexión.

Componente Azure Oracle Cloud Infrastructure
Red virtual VNet VCN
Circuito virtual Circuito de ExpressRoute Circuito virtual privado FastConnect
Gateway gateway de red virtual Gateway de enrutamiento dinámico (DRG)
Enrutamiento tablas de rutas tablas de rutas
Reglas de seguridad grupos de seguridad de red (NSG) grupos de seguridad de red (NSG), listas de seguridad

Previos necesarios: información de BGP necesaria

La conexión entre la VNet y la VCN utiliza el enrutamiento dinámico de BGP. Al configurar el circuito virtual de Oracle, proporcionará las direcciones IP BGP que se utilizarán para las dos sesiones BGP redundantes entre Oracle y Azure:

  • Un par fundamental de direcciones BGP (una dirección IP para Oracle y una dirección IP para Azure),
  • Un par de direcciones BGP secundario e independiente (una dirección IP para el lado de Oracle y una dirección IP para el de Azure).

Para cada par, debe proporcionar un bloque de direcciones independiente con una máscara de subred de /28 a /31.

La segunda y la tercera dirección de cada bloque de direcciones se utilizan para el par de direcciones IP BGP. En concreto:

  • La segunda dirección del bloque es para el lado de Oracle de la sesión BGP.
  • La tercera dirección del bloque es para el lado de Azure de la sesión BGP.

La primera y la última dirección del bloque se utilizarán para otros fines internos.

Por ejemplo, si el CIDR es 10.0.0.20/30, las direcciones del bloque serían:

  • 10.0.0.20
  • 10.0.0.21: use esto para el lado de Oracle (en la consola de Oracle, introduzca la dirección como 10.0.0.21/30)
  • 10.0.0.22: use esto para el lado de Azure (en la consola de Oracle, introduzca la dirección como 10.0.0.22/30 y tenga en cuenta que esta dirección se denomina lado del "Cliente" en la consola)
  • 10.0.0.23

Recuerde que también debe proporcionar un segundo bloque con el mismo tamaño para las direcciones BGP secundarias. Por ejemplo: 10.0.0.24/30. En este caso, 10.0.0.25 es para el lado de Oracle, y 10.0.0.26 es para el de Azure. En la consola de Oracle, debe introducirlas como 10.0.0.25/30 y 10.0.0.26/30.

Previos necesarios: política de IAM necesaria

Se da por supuesto que tiene el acceso necesario de Azure Active Directory y el de Oracle Cloud Infrastructure IAM para crear y trabajar con los recursos de red relevantes de Azure y Oracle. Concretamente, para IAM: si el usuario está en el grupo de Administradores, tiene la autoridad necesaria.

De no ser así, una política como esta cubrirá de modo general todos los recursos de Networking:

Allow group NetworkAdmins to manage virtual-network-family in tenancy

Para crear y gestionar únicamente un circuito virtual, debe tener una política como la siguiente:

Allow group VirtualCircuitAdmins to manage drgs in tenancy

Allow group VirtualCircuitAdmins to manage virtual-circuits in tenancy

Para obtener más información, consulte Políticas de IAM para Networking.

Proceso General

El siguiente diagrama muestra el proceso general de conexión de la VNet y la VCN.

En este diagrama de flujo de procesos se muestran los pasos para conectar la VNet de Azure y la VCN de Oracle
Tarea 1: configurar grupos de seguridad de red y reglas de seguridad

La primera tarea consiste en determinar qué debe fluir en el tráfico entre las subredes relevantes dentro de la VNet y la VCN y, a continuación, debe configurar los grupos de seguridad de la VNet y las reglas de seguridad de la VCN, según corresponda. Estos son los tipos generales de reglas que se deben agregar:

  • Reglas de entrada para los tipos de tráfico que desea permitir que entren en una nube desde la otra, concretamente, desde las subredes pertinentes de la otra nube.
  • Regla de salida para permitir el tráfico saliente de una nube a la otra. Si la subred de la VCN ya tiene una regla de salida amplia para todos los tipos de protocolos a todos los destinos (0.0.0.0/0), no es necesario agregar una especial para el tráfico a la VNet. La lista de seguridad por defecto de la VCN incluye una amplia regla de salida por defecto como esta.

En concreto, aquí se recomiendan tipos de tráfico entre la VNet y la VCN:

  • Hacer ping al tráfico en ambas direcciones para probar la conexión desde cada lado
  • SSH (puerto TCP 22),
  • Conexiones del cliente a una base de datos Oracle (SQL*NET en el puerto TCP 1521).

Permita el tráfico solo hacia los rangos de direcciones específicos de interés y desde estos (por ejemplo, las subredes pertinentes de la otra nube).

Para la VNet: determine las subredes de la VNet que se deben comunicar con la VCN. A continuación, configure los grupos de seguridad de red para esas subredes con el objetivo de permitir el tráfico.

Para la VCN:

Tenga

en cuenta que el siguiente procedimiento utiliza listas de seguridad, pero, en cambio, puede implementar las reglas de seguridad en uno o más grupos de seguridad de red y, a continuación, colocar los recursos relevantes de VCN en NSG.
  1. Determine cuáles son las subredes de la VCN que deben comunicarse con la VNet.
  2. Actualice la lista de seguridad de cada una de estas subredes para incluir reglas que permitan el tráfico de entrada o salida específicamente con el bloque CIDR de la VNet o una subred de la VNet:

    1. En la consola, mientras visualiza la VCN que le interesa, haga clic en Listas de seguridad.
    2. Haga clic en la lista de seguridad en la que está interesado.
    3. Haga clic en Editar todas las reglas y cree una o más reglas, cada una para el tipo de tráfico específico que desea permitir.

    4. Haga clic en Guardar reglas de la lista de seguridad en la parte inferior del cuadro de diálogo.

    Para obtener más información sobre la configuración de reglas de seguridad, consulte Reglas de seguridad.

Ejemplo: ping de salida desde la VCN hasta la VNet

La siguiente regla de seguridad de egreso permite a una instancia iniciar una solicitud de ping a un host fuera de la VCN (solicitud de eco de ICMP tipo 8). Se trata de una regla con estado que permite la respuesta de forma automática. No se necesita ninguna regla de entrada diferente para la respuesta de eco ICMP tipo 0.

  1. En la sección Permitir reglas para salida, haga clic en Regla +Add.
  2. Deje desactivada la casilla Sin estado.
  3. El CIDR de destino: subred relevante en la VNet (10.0.0.0/16 en el diagrama anterior)
  4. Protocolo IP: ICMP
  5. Tipo y código: 8
  6. Descripción: descripción opcional de la regla.
Ejemplo: ping entrante a la VCN desde la VNet

La siguiente regla de seguridad de entrada permite a una instancia recibir una solicitud de ping de un host en la VNet (solicitud de eco de ICMP tipo 8). Se trata de una regla con estado que permite la respuesta de forma automática. No es necesaria ninguna regla de salida independiente para la respuesta de eco de ICMP tipo 0.

  1. En la sección Permitir reglas para entrada, haga clic en +Agregar regla.
  2. Deje desactivada la casilla Sin estado.
  3. El CIDR de origen: subred relevante en la VNet (10.0.0.0/16 en el diagrama anterior)
  4. Protocolo IP: ICMP
  5. Tipo y código: 8
  6. Descripción: descripción opcional de la regla.
Ejemplo: SSH entrante a la VCN

La siguiente regla de seguridad de entrada permite a una instancia recibir una conexión SSH (puerto TCP 22) de un host en la VNet.

  1. En la sección Permitir reglas para entrada, haga clic en +Agregar regla.
  2. Deje desactivada la casilla Sin estado.
  3. El CIDR de origen: subred relevante en la VNet (10.0.0.0/16 en el diagrama anterior)
  4. Protocolo IP: TCP
  5. Rango de puertos de origen: Todos
  6. Rango de puerto de destino: 22
  7. Descripción: descripción opcional de la regla.
Ejemplo: conexiones SQL*Net a la base de datos

La siguiente regla de seguridad de entrada permite conexiones de SQL*Net (puerto TCP 1521) desde los hosts en la VNet.

  1. En la sección Permitir reglas para entrada, haga clic en +Agregar regla.
  2. Deje desactivada la casilla Sin estado.
  3. El CIDR de origen: subred relevante en la VNet (10.0.0.0/16 en el diagrama anterior)
  4. Protocolo IP: TCP
  5. Rango de puertos de origen: Todos
  6. Rango de puerto de destino: 1521
  7. Descripción: descripción opcional de la regla.
Tarea 2: configurar el circuito de Azure ExpressRoute

Configure un circuito ExpressRoute a Oracle Cloud Infrastructure FastConnect. Durante la configuración del circuito, recibirá una clave de servicio de Microsoft. Conserve esa clave de servicio, ya que debe proporcionarla a Oracle en la siguiente tarea.

En la siguiente tarea configurará un circuito virtual privado de FastConnect a Microsoft Azure: ExpressRoute. Cuando ese circuito virtual termina de aprovisionarse, el circuito de ExpressRoute se actualiza para mostrar que el intercambio de tráfico privado está activado.

Tarea 3: configurar un circuito virtual de Oracle Cloud Infrastructure FastConnect
  1. En la consola, confirme que está viendo el compartimiento en el que desea trabajar. Si no está seguro cuál, utilice el compartimiento que contiene el DRG al que se conectará. La elección de compartimento, junto con la política de IAM correspondiente, controla quién tiene acceso al circuito virtual que va a crear.
  2. Abra el menú de navegación y haga clic en Redes. En Conectividad de cliente, haga clic en FastConnect.

    La página FastConnect resultante es donde ha creado un nuevo circuito virtual y, posteriormente, deberá volver cuando necesite gestionar este circuito.

  3. Haga clic en Crear Conexión.
  4. Seleccione Partner de FastConnect y elija Microsoft Azure: ExpressRoute en la lista.
  5. Introduzca lo siguiente para su circuito virtual:

    • Nombre: nombre fácil de recordar de su elección. El valor no tiene que ser único en sus circuitos virtuales y puede cambiarlo posteriormente. Evite introducir información confidencial.
    • Crear en compartimiento: déjelo tal cual (el compartimiento en el que se encuentra trabajando actualmente).
    • Tipo de circuito virtual: seleccione Circuito virtual privado.
    • Compartimiento de gateway de enrutamiento dinámico seleccione el compartimiento donde reside el DRG (ya debe estar seleccionado).
    • Gateway de enrutamiento dinámico: seleccione el DRG.
    • Ancho de banda provisionado: elija el mismo nivel de ancho de banda que seleccionó para el circuito de ExpressRoute (o el valor más cercano disponible).
    • Clave de servicio de partner: introduzca la clave de servicio recibida de Microsoft al configurar el circuito de ExpressRoute.
    • Dirección IP BGP principal del cliente: es la dirección IP BGP principal de Azure. Introduzca la tercera dirección en el bloque de CIDR principal (con una máscara de subred de /28 a /31) que proporcione e incluya la máscara de subred al final. Por ejemplo: 10.0.0.22/30. Para obtener más información sobre este campo y los siguientes, consulte Configuración de una conexión desde la VNet hasta la VCN.
    • Dirección IP BGP principal de Oracle (opcional): puede dejar este campo en blanco y Oracle inferirá la dirección basada en el bloque de CIDR que ha proporcionado para la dirección IP BGP de Azure. En este ejemplo, el valor correcto sería 10.0.0.21/30.
    • Dirección IP BGP secundaria del cliente: es la dirección IP BGP secundaria de Azure. Introduzca la tercera dirección en el bloque de CIDR secundario (con una máscara de subred de /28 a /31) que proporcione e incluya la máscara de subred al final. Por ejemplo: 10.0.0.26/30.
    • Dirección IP BGP principal de Oracle (opcional): puede dejar este campo en blanco y Oracle inferirá la dirección basada en el bloque de CIDR que ha proporcionado para la dirección IP BGP de Azure. En este ejemplo, el valor correcto sería 10.0.0.25/30.
  6. Haga clic en Continuar.

    Se ha creado el circuito virtual.

  7. Haga clic en Cerrar.

Después de crear el circuito virtual de Oracle, no es necesario que se ponga en contacto con Azure para solicitar el aprovisionamiento del circuito. Esto sucede de modo automático.

Tarea 4: confirmar el aprovisionamiento de ambos circuitos

En unos minutos, se deben aprovisionar ambos circuitos. Para verificar:

Tarea 5: configurar las tablas de rutas

Para la VNet: determine las subredes de la VNet que se deben comunicar con la VCN. A continuación, configure las tablas de rutas para que esas subredes dirijan el tráfico al gateway de la VNet.

Para la VCN:

  1. Determine cuáles son las subredes de la VCN que deben comunicarse con la VNet.
  2. Actualice la tabla de rutas de cada una de esas subredes para incluir una nueva regla que dirija el tráfico destinado al CIDR de la VNet a la DRG:

    1. En la consola, mientras visualiza la VCN que le interesa, haga clic en Tablas de rutas.
    2. Haga clic en la tabla de rutas que le interesa.
    3. Haga clic en Editar reglas de ruta.
    4. Haga clic en + Otra regla de ruta e introduzca lo siguiente:

      • Tipo de destino: gateway de enrutamiento dinámico. El DRG asociado de la VCN se selecciona automáticamente como destino y no tiene que especificarlo usted mismo.
      • Bloque CIDR de destino: la subred relevante en la VNet (10.0.0.0/16 en el diagrama anterior).
      • Descripción: descripción opcional de la regla.
    5. Haga clic en Guardar.

Todo el tráfico de subred con un destino que coincida con la regla se direcciona al DRG. A continuación, el DRG sabe que dirigirá el tráfico a la VNet gracias a la información de sesión BGP del circuito virtual.

Más adelante, si ya no necesita la conexión y desea suprimir el DRG, primero debe empezar por todas las reglas de ruta de la VCN que especifican el DRG como destino.

Para obtener más información sobre la configuración de reglas de ruta, consulte Tablas de rutas de VCN.

Tarea 6: probar la conexión

En función de cómo haya configurado los grupos de seguridad de la VNet y las reglas de seguridad de las VCN, podrá crear una instancia en la VCN y acceder a ella desde un host en la VNet. O bien, debe poder conectarse desde la instancia a un host en la VNet. Si lo consigue, la conexión estará lista para su uso.

Importante

si decide terminar la conexión, deberá seguir un proceso concreto. Consulte Finalizar la conexión a Azure.

Gestión de una conexión desde la VNet hasta la VCN

Para obtener el estado del circuito virtual de FastConnect
  1. Abra el menú de navegación y haga clic en Redes. En Conectividad de cliente, haga clic en FastConnect.
  2. Seleccione el compartimiento donde reside la conexión y, a continuación, haga clic en la conexión que le interesa. Si el icono del circuito virtual es verde e indica ACTIVO en él, esto significa que el circuito virtual está aprovisionado y que la BGP se ha configurado correctamente. El circuito virtual está listo para usar.
Edición de un circuito virtual de FastConnect

Puede cambiar estos elementos para su circuito virtual:

  • El nombre
  • Qué DRG utiliza
Atención

si el circuito virtual tiene el estado APROVISIONADO, al cambiar el DRG que utiliza, cambiará el estado a APROVISIONANDO y puede causar que se cierre la conexión. Una vez que Oracle vuelve a aprovisionar el circuito virtual, su estado vuelve a APROVISIONADO. Confirme que la conexión está activa y en funcionamiento.
  1. Abra el menú de navegación y haga clic en Redes. En Conectividad de cliente, haga clic en FastConnect.
  2. Seleccione el compartimiento donde reside la conexión y, a continuación, haga clic en ella.
  3. Haga clic en el circuito virtual.
  4. Haga clic en Editar y realice los cambios. Evite introducir información confidencial.
  5. Haga clic en Guardar.
Finalización de la conexión a Azure

El siguiente diagrama muestra el proceso general de terminación de una conexión desde la VNet hasta la VCN.

Este diagrama de flujo muestra los pasos para finalizar la conexión desde la VNet hasta la VCN
  1. En el portal de Azure, vea el circuito de ExpressRoute y, a continuación, vea sus conexiones. Confirme que todavía no existan conexiones en el circuito de ExpressRoute. Suprima todas lasConexiones para poder continuar.
  2. En el portal de Oracle, suprima el circuito virtual de FastConnect:

    1. Abra el menú de navegación y haga clic en Redes. En Conectividad de cliente, haga clic en FastConnect.
    2. Seleccione el compartimiento donde reside la conexión y, a continuación, haga clic en ella.
    3. Haga clic en el circuito virtual.
    4. Haga clic en Suprimir.
    5. Confirme cuando se le solicite.

      El estado de ciclo de vida del circuito virtual cambia a FINALIZANDO.

  3. En el portal de Azure, confirme que se ha suprimido el intercambio de tráfico privado para el circuito de ExpressRoute. Confirme, también, que el estado del circuito de ExpressRoute ha cambiado a" No aprovisionado".
  4. En el portal de Azure, suprima el circuito de ExpressRoute.

La conexión entre Azure y Oracle Cloud Infrastructure ha finalizado.