Incidencias conocidas de red

Estas incidencias conocidas se han identificado en la familia de servicios de Networking, incluidas las conexiones internas dentro de una VCN y la conectividad con las redes locales.

Consulte también: Troubleshooting VCNs and Connectivity.

FTP activo no soportado en instancias de Windows

Detalles
El cliente FTP por defecto proporcionado por Microsoft Windows solo admite FTP en modo activo, que no funciona con las reglas de firewall con estado de Oracle o con instancias desplegadas detrás de un gateway de NAT.
Solución alternativa
Oracle recomienda que las instancias de Windows utilicen un cliente FTP de terceros que se ejecute en modo pasivo.

Problema del asistente de configuración de CPE al especificar el proveedor de CPE

Detalles

Si ocurre lo siguiente, en la consola de Oracle recibirá un error que indica que falta la información del proveedor en el CPE (tipo de dispositivo). Actualice el CPE y agregue la información del proveedor:

  • Tiene un CPE que existía antes de que se lanzara la función Configuration Helper de CPE.
  • Aún no ha editado el CPE en la consola de Oracle y ha especificado el proveedor que corresponde con su CPE.
  • Ha intentado generar el contenido de Helper para el CPE o cualquier conexión de IPSec que utilice ese CPE.
Solución alternativa

Realice las siguientes acciones:

  1. En la consola de Oracle, visualice el CPE.
  2. Haga clic en Editar.
  3. En la sección Información de proveedor de CPE, seleccione el proveedor que corresponde con su CPE. Si no está seguro de cuál es el proveedor que se corresponde con su CPE o no aparece en la lista, seleccione Otro.
  4. Si se le solicita, seleccione un valor para Plataforma/Versión. Estas son las directrices:

    • Oracle recomienda utilizar una configuración basada en rutas si es posible.
    • Si no ve su plataforma o versión de CPE específica en la lista, seleccione la plataforma o versión más cercana que preceda a su versión de CPE.
  5. Haga clic en Guardar cambios. Es importante hacer clic aquí incluso si no ha cambiado el valor del proveedor.

A continuación, puede generar el contenido de Helper correctamente para el CPE o cualquier conexión de IPSec que utilice ese CPE.

Problemas de acceso privado desde su red local a Oracle Analytics Cloud mediante un gateway de servicios

Detalles
Si realiza todo lo siguiente, se puede producir un enrutamiento asimétrico para el tráfico entre la red local y Oracle Analytics Cloud: El enrutamiento asimétrico implica que el tráfico de solicitud y respuesta pasa por rutas diferentes. Aquí tiene más detalles de por qué se puede producir el enrutamiento asimétrico: cuando Oracle Analytics Cloud inicia conexiones a clientes en la red local, las solicitudes de conexión deben pasar por una ruta pública (ya sea el intercambio de tráfico público de Internet o FastConnect). Sin embargo, la respuesta recorre una ruta privada, en función de la recomendación en Preferencias de enrutamiento para el tráfico desde su red local hasta Oracle.
Solo se necesita una solución alternativa si utiliza Oracle Analytics Cloud para iniciar conexiones a clientes de la red local y aún usa un gateway de datos en la red.
Solución alternativa 1 (preferida)
Con Oracle Analytics Cloud, cambie de un conector de datos remoto a un gateway de datos .
Solución alternativa 2
Configure el equipo local de cliente (CPE) para que prefiera una ruta de intercambio de tráfico pública de Internet o FastConnect agregando rutas estáticas para la dirección IP de origen regional para Oracle Analytics Cloud. De este modo, todo tráfico de respuesta a Oracle Analytics Cloud devolverá la misma ruta de acceso que la solicitud de conexión entrante.

Problemas con el acceso a las instancias públicas de los servicios de Oracle a través de un gateway de servicios

Detalles
Si la tabla de rutas asociada a su subred pública en una VCN incluye las dos reglas de ruta en conflicto siguientes, es posible que los servicios de Oracle no puedan acceder a sus instancias públicas en esa subred.
  1. Regla de ruta con el tipo de destino definido como gateway de Internet.
  2. Regla de ruta con el servicio de destino definido como Todos los servicios de <region> de Oracle Services Network y el tipo de destino definido como gateway de servicio.
Las dos reglas de ruta anteriores pueden conducir al enrutamiento asimétrico cuando los servicios de Oracle inician conexiones a instancias públicas en la red virtual en la nube. Oracle Cloud Infrastructure no admite estas reglas simultáneamente en la misma tabla de rutas. Oracle ha actualizado las API de servicio y la Consola para desactivar el soporte para esta configuración.
Solución alternativa

Se recomienda eliminar la regla de ruta que tiene el servicio de destino definido como Todos los servicios de <region> en Oracle Services Network y el tipo de destino definido como gateway de servicio. Revierta a la configuración que utilizaba antes de adoptar el gateway de servicios para Oracle Services Network. Con este cambio, las instancias públicas mantienen el acceso a todos los servicios de Oracle a través del gateway de Internet. Los servicios de Oracle pueden seguir accediendo a sus instancias públicas.

Sin embargo, sus instancias en la subred pública pueden seguir accediendo al almacenamiento de objetos mediante el gateway de servicios. Actualice la tabla de rutas de la subred para que incluya una regla de ruta con el servicio de destino definido como Object Storage de <region> de OCI y el destino definido en el gateway de servicio de la red virtual en la nube.

Este problema conocido solo se aplica a las subredes públicas que tienen acceso a un gateway de Internet. Con respecto a las subredes privadas, puede configurar la tabla de rutas de una subred privada para proporcionar acceso a Todos los servicios de ><region> de Oracle Services Network o a Object Storage de <region> de OCI a través del gateway de servicios de la red virtual en la nube.

Problemas de acceso de instancias a servicios de yum de Oracle a través del gateway de servicio

Detalles
Si desea utilizar un gateway de servicio con la VCN sin utilizar también un gateway de Internet o un gateway de NAT para el acceso a Internet, puede que sus instancias no tengan acceso al servidor regional de yum de Oracle aplicable. Hay dos posibles incidencias:
  • Las instancias creadas antes de noviembre de 2018 podrían tener sus repositorios apuntando a direcciones URL a las que no se puede acceder a través del gateway de servicios
  • Las instancias que no han podido contactar con el servidor de yum de su región local pueden haber recurrido a yum.oracle.com, al que no se puede acceder mediante el gateway de servicios
Para utilizar cualquiera de las siguientes estrategias de mitigación, debe tener uno de los siguientes gateways configurados para poder comunicarse con el servidor de yum de la región: gateway de servicio, gateway de NAT o gateway de Internet.
Solución alternativa 1 (automática)

Pruebe la siguiente mitigación automatizada. Si falla por algún motivo, use el método de mitigación manual que se indica a continuación.

Copie la siguiente secuencia de comandos en el sistema local y ejecútela. La secuencia de comandos desactiva los repositorios existentes y descarga el archivo repo, que dirige el sistema a los servidores yum locales de la región a los que se puede acceder mediante el gateway de servicios.

#!/bin/bash
REPODIR='/etc/yum.repos.d'
REPOS=$REPODIR/*
REGION=$(curl -sfm 3 http://169.254.169.254/opc/v1/instance/ | jq -r '.region' | cut -d '-' -f 2)
VERSION=$(egrep '^VERSION_ID' /etc/os-release | cut -d '"' -f 2 | cut -d '.' -f 1)
REPOURL="http://yum-${REGION}.oracle.com/yum-${REGION}-ol${VERSION}.repo"

echo "Disabling existing repos"
for i in $REPOS
do
  if [[ "$i" != *".disabled" ]]; then
    mv $i $i.disabled
    echo "$i disabled"
  else
    echo "$i repofile already disabled"
  fi
done
yum clean all
echo "Pulling new regional repository file"
wget -q $REPOURL -O "$REPODIR/yum-${REGION}-ol${VERSION}.repo"
retval=$?
if [[ "$retval" -ne 0 ]]; then
  echo "Unable to pull repo file, please run manual steps"
  exit 1
fi
yum makecache fast
Solución alternativa 2 (manual)

Si se produce un fallo en la mitigación automatizada, puede mitigar el problema manualmente. Aquí puede desactivar los archivos de repositorio existentes y extraer el último archivo de repositorio del servidor de yum de su región. Para identificar la clave de región de la instancia, consulte la lista de regiones en Regiones y dominios de disponibilidad.

Para desactivar los archivos de repositorio existentes, navegue al directorio /etc/yum.repos.d y cambie el nombre de todos los archivos presentes para incluir .disabled al final del nombre de archivo.

Por ejemplo:

ls /etc/yum.repos.d ksplice-uptrack.repo.disabled public-yum-ol7.repo.disabled

Descargue el archivo de repositorio de su región en el sistema local. En el siguiente ejemplo se utiliza Ashburn (con la clave de región iad). Sustituya iad por la clave de región aplicable a la instancia.

cd /etc/yum.repos.d/
wget http://yum-iad.oracle.com/yum-iad-ol7.repo
chown root:root yum-iad-ol7.repo
yum makecache fast