Solución de problemas de red

En la página se explica cómo solucionar problemas habituales de red.

Solución de problemas de arranque de red

En esta sección se muestran algunos de los errores habituales que pueden surgir al completar el proceso de arranque de la red.

Error de generación de la configuración

Para completar la instalación de la red, se instalan archivos de configuración de red en el equipo de arranque. Si se produce un error al generar la configuración, consulta los archivos YAML ubicados en /root/cellcfg para ver la configuración del interruptor que ha fallado.

El arranque se ha detenido en la fase 1 de ping

Si el proceso de arranque de la red se detiene en la fase 1 de ping, sigue estos pasos para identificar el problema:

  1. Obtén la ubicación de la configuración del interruptor generado en el registro de arranque: /tmp/network-bootstrap/ID
  2. Busca el conmutador bloqueado consultando el archivo de configuración del conmutador con la dirección IP.
  3. Inicia sesión en el interruptor y consulta el registro de operaciones.

Bootstrap se ha detenido en la fase 2 de ping

Si el proceso de arranque de la red se detiene en la fase 2 de ping, sigue estos pasos para identificar el problema:

  1. Obtén la ubicación de la configuración del interruptor generado en el registro de arranque: /tmp/network-bootstrap/ID
  2. Busca el conmutador bloqueado consultando el archivo de configuración del conmutador con la dirección IP de gestión.
  3. Comprueba la configuración del conmutador de gestión para detectar posibles problemas de acceso en la red de gestión.

Solucionar problemas de conciliación de redes del día 2

Información general

GDC usa la función de sustitución de la configuración que proporciona Cisco NX-OS durante la conciliación de los switches para sustituir la configuración en ejecución de un switch por una configuración completamente nueva. Estos son los pasos que sigue internamente la operación de sustitución de la configuración:

  1. Calcula la diferencia entre la configuración actual y la configuración proporcionada por el usuario.
  2. Genera un archivo de parche que es la diferencia entre la configuración en ejecución y la configuración de entrada.
  3. Realiza una validación semántica en el archivo de parche.
  4. Aplica el archivo de parche.
  5. Verifica que el archivo de parche se ha añadido correctamente comparando la configuración en ejecución con la configuración de entrada. De lo contrario, se volverá a la configuración anterior.
  6. Se inicia un temporizador antes del cual se debe ejecutar el comando configure replace commit o se revierte la nueva configuración.

Puede producirse un error en cualquiera de los pasos anteriores, pero lo más habitual es que se produzca en los pasos 3, 4 y 1. A continuación, se indican algunas formas de solucionar errores con configure replace.

Pasos para solucionar problemas comunes

Comprobar el estado general del interruptor

En el servidor de administrador raíz, ejecuta kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system (sustituye el nombre del interruptor por el nombre del interruptor necesario).

El objeto de Kubernetes del administrador raíz muestra los registros de ejecución y verificación en la descripción del objeto si falla la última sustitución de la configuración.

Comprobar el estado de la última operación de sustitución de la configuración

En la consola de conmutación, ejecuta show config-replace status:

El estado proporcionará la siguiente información:

  • Estado general, como "completo", "error", etc.
  • Indica si se ha confirmado la sustitución de la configuración o si está pendiente de confirmación.
  • Hora de inicio y de finalización de la última operación de sustitución de la configuración

Comprobar qué configuraciones se aplicaron en la última operación de sustitución de la configuración

En la consola de conmutación, ejecuta show config-replace log exec.

El registro de ejecución de sustitución de configuración muestra los registros generados al aplicar las configuraciones que se determinaron mediante la operación de sustitución de configuración como la configuración de parche, es decir, la diferencia entre la configuración en ejecución y la configuración de entrada.

Ten en cuenta que estos registros a veces tienen errores que ignora la operación de sustitución de la configuración y que no provocan que la sustitución de la configuración falle por completo. A menos que un error sea la última línea del registro de ejecución de la sección "Executing Patch" (Ejecutando parche), es probable que no sea la causa de un fallo en la sustitución de la configuración.

Comprueba si la verificación de la última operación de sustitución de la configuración se ha realizado correctamente.

En la consola de conmutación, ejecuta show config-replace log verify.

Después del paso de ejecución de la sustitución de la configuración, la operación de sustitución de la configuración compara la nueva configuración en ejecución del conmutador con la configuración de entrada. Estas configuraciones deben coincidir. Si no es así, la sustitución de la configuración fallará y se restaurará la configuración anterior.

El registro de verificación tiene dos secciones.

  • Configuration To Be Added Missing in Running-config: muestra las configuraciones que están presentes en la configuración de entrada, pero no en la nueva configuración en ejecución.
  • Configuration To Be Removed Present in Running-config: muestra las configuraciones que están presentes en la nueva configuración en ejecución, pero no en la configuración de entrada.

Consultar todos los comandos que se han ejecutado en el interruptor

En la consola del interruptor, ejecuta show accounting log start-time 2022 Sep 13 20:00:00 (sustituyendo la hora de inicio por la hora de inicio obligatoria).

Los registros de contabilidad muestran todos los comandos que se ejecutan en el switch. Estos registros pueden ser útiles para ver qué comandos se han ejecutado en el switch a través de NXAPI o manualmente. También pueden darte una idea de cuándo se ejecutó exactamente cada operación de sustitución de configuración y cuántas veces se ha ejecutado.

Comprobar qué llamadas a la API NX se han realizado al switch y desde dónde

En la consola de Switch, ejecuta show nxapi-server logs.

Los registros de NX-API muestran los registros relacionados con las llamadas a NXAPI realizadas al switch. Dado que nuestra pila de automatización hace llamadas a la API NX a los conmutadores por muchos motivos, incluido el de ejecutar la sustitución de la configuración, es útil ver qué llamadas a la API NX se han realizado y de dónde proceden.

Solución de problemas de interconexión

Información general sobre la API Interconnect

La API Interconnect configura las conexiones externas de una celda de centro de datos de GDC. Hay tres tipos de interconexiones

  • Interconexión de centros de datos (DCI): interconexión de un centro de datos de GDC con otro centro de datos de GDC a través de los switches de hoja de borde del plano de datos.
  • Interconnect de peering de cliente (CPI): interconexión desde un centro de datos de GDC a la red de la organización a través de los switches de hoja de borde del plano de datos.
  • Centro de operaciones de red (NOC): interconexión desde un centro de datos de GDC al centro de operaciones de red a través de los conmutadores de hoja de borde del plano de datos y los conmutadores de agregación de gestión.

Están presentes los siguientes objetos de la API:

  • InterconnectLink: este objeto de API define los puertos físicos que se conectan a conmutadores externos.

  • InterconnectAttachment: este objeto de API define los archivos adjuntos que hay además de la InterconnectLink configurada. La información que contiene cada archivo adjunto define lo siguiente:

    1. Tipo de interconexión
    2. Información de BGP
    3. Información del ID de VLAN
    4. Políticas de ruta configuradas

  • RoutePolicy: este objeto de API modela las políticas que se usan para compartir rutas con peers BGP de interconexión.

Solución de problemas

Los objetos de la API InterconnectLink y InterconnectAttachment exponen una gran cantidad de información que puede arrojar luz sobre el estado actual.

  • InterconnectLink: Se expone la siguiente información de cada puerto físico que se conecta a conmutadores externos.

    1. Up: información sobre el estado del puerto (activo o inactivo).
    2. DownReason: motivo por el que el puerto está inactivo.

  • InterconnectAttachment: Se expone la siguiente información de cada uno de los adjuntos de Interconnect configurados.

    1. BGPStatus: estado de la sesión de BGP (por ejemplo, Activa o Inactiva).
    2. UpTime: marca de tiempo de la última vez que se activó la sesión de BGP.
    3. PrefixCounters: contadores que muestran el total de prefijos Received, Sent y Withdrawn.

Verificar las políticas de ruta

RoutePolicy define una lista de prefijos y la acción que se debe llevar a cabo (por ejemplo, Permitir o Denegar). Lista todas las políticas de ruta asociadas al recurso InterconnectAttachment para verificar si las direcciones IP forman parte de RoutePolicy válidas.

Verificar los prefijos de ruta o el tráfico de BGP en los conmutadores de hoja de frontera a través de cortafuegos

La ruta de datos de la interconexión también atraviesa dos cortafuegos de PANW: el cortafuegos del sistema de detección y prevención de intrusos (IDPS) y el cortafuegos perimetral. Aunque los prefijos de ruta se aprendan de la sesión de BGP, es posible que los cortafuegos los descarten.

Verificar los prefijos de ruta aprendidos en varios VRFs

El tráfico externo atraviesa varias VRFs en los conmutadores de agregación a medida que transita por los diferentes firewalls. Comprobar los prefijos de ruta BGP aprendidos en estos puntos de VRF para detectar prefijos de ruta o tráfico descartado en los cortafuegos.

Todo el tráfico externo se coloca en los VRFs externos *-external-vrf en función del clúster de origen o de destino del tráfico en los conmutadores de hoja de borde. Ejemplo: root-external-vrf tiene tráfico con origen o destino al clúster de administrador raíz.

Una vez que el tráfico atraviesa el cortafuegos IDPS, se coloca en uno de los siguientes VRFs de interconexión:

  • oc-vrf
  • dci-vrf
  • cp-vrf

En el caso del tráfico destinado al NOC, hay un firewall perimetral adicional después del cual el tráfico llega a octransit-vrf.

Inicia sesión en los conmutadores de hoja de borde y usa el siguiente comando para mostrar los prefijos de ruta aprendidos en varias VRFs:

show bgp vrf <vrf_name> all

Donde vrf_name puede ser uno de los VRFs.

Solución de problemas de BGP de ANG

Archivo kubeconfig del clúster

Asegúrese de que tiene los siguientes valores de KUBECONFIG_FILE para comprobar los objetos:

  • ROOT_ADMIN_KUBECONFIG: el archivo kubeconfig del clúster de administrador raíz.
  • ORG_ADMIN_KUBECONFIG: el archivo kubeconfig del clúster de administrador de la organización.
  • ORG_SYSTEM_KUBECONFIG: el archivo kubeconfig del clúster del sistema de organización.
  • ORG_USER_KUBECONFIG: el archivo kubeconfig del clúster de usuarios de la organización.

El clúster se ha bloqueado en el estado de aprovisionamiento

  1. Verifica que el objeto NodePool esté listo.

    kubectl --kubeconfig KUBECONFIG_FILE \
    get nodepools -A

    Si los objetos de nodepool no se crean o no están listos, comprueba NodePoolClaim y la conectividad de los nodos.

  2. Verifica que el objeto ClusterBGPPeer esté listo.

    Verifica que se hayan creado los objetos ClusterBGPPeer para flat-ip-bgp-x, lb-bgp-x y node-x:

    kubectl --kubeconfig KUBECONFIG_FILE \
    get clusterbgppeers -A
...
ORG_NAME-system-cluster   flat-ip-bgp-peer-0                   16h
ORG_NAME-system-cluster   lb-bgp-peer-0                        21h
ORG_NAME-system-cluster   node-10.251.100.10-peer-10.0.224.0   21h

    Si no se crean objetos, comprueba los objetos NetworkGatewayGroup y BGPPeer.

  3. Comprueba que los BGPSession estén activos.

    kubectl --kubeconfig KUBECONFIG_FILE \
    get bgpsessions -A

    Si las sesiones de BGP no están activas, consulta Las sesiones de BGP no se han establecido.

Sesión de BGP no establecida

Consulta EBGPNeighbor en TORSwitchInternal

  1. Consulta ClusterBGPRouter para obtener el interruptor TOR emparejado de cada interfaz.

    Las interfaces de ORG_NAME ClusterBGPRouter se usan para emparejar todos los clústeres de ORG_NAME.

     apiVersion: network.private.gdc.goog/v1alpha1
 kind: ClusterBGPRouter
 metadata:
 labels:
     clusterbgpreconciler.system.private.gdc.goog/overlay-network: external
 name: external-vrf-cluster-bgp-router
 namespace: ORG_NAME
 spec:
 clusterASN: 64513
 interfaces:
 - ip: 10.0.252.48
   switchMetadata:
   rackName: alatl14-aa
   switchRef:
       kind: TORSwitch
       name: alatl14-aa-torsw01
 - ip: 10.0.252.49
   switchMetadata:
   rackName: alatl14-aa
   switchRef:
       kind: TORSwitch
       name: alatl14-aa-torsw02
 networkASN: 65014

  2. En cada TORSwitchInternal, comprueba spec.ebgpNeighbors para ver si se han configurado todos los objetos ClusterBGPPeer.

Depurar sesiones de BGP en conmutadores TOR

  1. Conéctate por SSH a uno de los TOR switches emparejados.

  2. Verifica los vecinos BGP de ANG para ORG_NAME:

    > sh run bgp
router bgp 65014
...
  vrf ORG_NAME-external-vrf
    ...
    neighbor 10.251.100.3
      inherit peer ANG
      update-source loopback200
    neighbor 10.251.100.4
      inherit peer ANG
      update-source loopback200
    ...
  vrf ORG_NAME-internal-vrf
    ...
    neighbor 172.20.128.5
      inherit peer ANG
      update-source loopback100
    neighbor 172.20.128.6
      inherit peer ANG
      update-source loopback100
  ...

  3. Comprueba el estado de la sesión de BGP:

    > sh bgp ses vrf ORG_NAME-external-vrf
> sh bgp ses vrf ORG_NAME-internal-vrf

  4. Para ver los registros de BGP, haz lo siguiente:

    > debug ip bgp all
> no debug ip bgp all (disable log mode)

  5. Mueve la depuración con bash:

    > run bash
> sudo tcpdmp -i any port 179 -vvv