Se usó la API de Cloud Translation para traducir esta página.

Solución de problemas de redes

En la página, se proporcionan detalles para solucionar problemas de redes comunes.

Solución de problemas de arranque de red

En esta sección, se muestran algunos de los errores comunes que puedes encontrar cuando completas el proceso de arranque de la red.

Error de generación de la configuración

Para completar la instalación de red, se instalan archivos de configuración de red en la máquina de arranque. Si se produce un error de generación de la configuración, verifica los archivos YAML ubicados en /root/cellcfg para ver la configuración del conmutador que falló.

El arranque se detuvo en el ping de la fase 1

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

Obtén la ubicación de la configuración del interruptor generada en el registro de arranque: /tmp/network-bootstrap/ID
Para encontrar el conmutador atascado, consulta el archivo de configuración del conmutador con la dirección IP.
Accede al conmutador y verifica el registro de operaciones.

El arranque se detuvo en el ping de la fase 2

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

Obtén la ubicación de la configuración del interruptor generada en el registro de arranque: /tmp/network-bootstrap/ID
Para encontrar el conmutador atascado, consulta el archivo de configuración del conmutador con la dirección IP de administración.
Verifica la configuración del conmutador de administración para detectar posibles problemas de acceso en la red de administración.

Solución de problemas de conciliación del día 2 de la red

Descripción general

GDC usa la función de reemplazo de configuración que proporciona Cisco NX-OS durante la reconciliación del conmutador para reemplazar la configuración en ejecución de un conmutador por una configuración completamente nueva. Los pasos que realiza internamente la operación de reemplazo de configuración son los siguientes:

Calcula la diferencia entre la configuración en ejecución actual y la configuración proporcionada por el usuario.
Genera un archivo de parche que muestra la diferencia entre la configuración en ejecución y la configuración de entrada.
Realiza la validación semántica en el archivo de parche.
Aplica el archivo de parche.
Verifica que el archivo de parche se haya agregado correctamente comparando la configuración en ejecución con la configuración de entrada. De lo contrario, se revierte a la configuración anterior.
Se inicia un temporizador antes del cual se debe ejecutar el comando configure replace commit o se revierte la configuración nueva.

El error puede ocurrir en cada uno de los pasos anteriores, pero, con mayor frecuencia, se produce durante los pasos 3, 4 y 1. A continuación, se indican algunas formas de solucionar problemas relacionados con la opción de configuración de reemplazo.

Pasos comunes para solucionar problemas

Cómo verificar el estado general del cambio

En el servidor de administración raíz, ejecuta kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system (reemplaza el nombre del parámetro de configuración por el nombre requerido).

El objeto de Kubernetes de conmutación en el clúster de administrador raíz muestra los registros de verificación y ejecución en la descripción del objeto si falla el último reemplazo de configuración.

Verifica el estado de la última operación de reemplazo de configuración

En la consola del conmutador, ejecuta show config-replace status:

El estado proporcionará la siguiente información:

Estado general, como "completo", "falla", etcétera
Indica si se confirmó el reemplazo de la configuración o si está en espera de confirmación.
Hora de inicio y finalización de la última operación de reemplazo de configuración

Verifica qué parámetros de configuración se aplicaron en la última operación de reemplazo de la configuración

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

El registro de ejecución de reemplazo de configuración muestra los registros generados durante la aplicación de las configuraciones que se determinaron mediante la operación de reemplazo 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, a veces, estos registros tienen errores que la operación de reemplazo de configuración ignora y que no hacen que falle el reemplazo de configuración en su totalidad. A menos que un error sea la última línea del registro de ejecución en la sección "Executing Patch", es probable que no sea la causa de una falla en el reemplazo de la configuración.

Verifica si la verificación de la última operación de reemplazo de configuración se realizó correctamente

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

Después del paso de ejecución de reemplazo de configuración, la operación de reemplazo de 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í, el reemplazo de la configuración falla y se revierte a la configuración anterior.

El registro de verificación tiene dos secciones.

Configuration To Be Added Missing in Running-config: Enumera 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: En esta lista, se incluyen las configuraciones que están presentes en la nueva configuración en ejecución, pero no en la configuración de entrada.

Verifica todos los comandos que se ejecutaron en el conmutador.

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

Los registros de contabilidad muestran todos los comandos que se ejecutan en el conmutador. Estos registros pueden ser útiles para ver qué comandos se ejecutaron en el conmutador a través de la NXAPI o de forma manual. También pueden darte una idea de cuándo se ejecutó exactamente cada operación de reemplazo de configuración y cuántas veces se ejecutó.

Verificar qué llamadas a la NX-API se realizaron al conmutador y desde dónde

En la consola de conmutación, ejecuta show nxapi-server logs.

Los registros de la NX-API muestran los registros relacionados con las llamadas a la NXAPI realizadas al conmutador. Dado que nuestra pila de automatización realiza llamadas a la NXAPI a los conmutadores por muchos motivos, incluido el de ejecutar el reemplazo de la configuración, resulta útil ver qué llamadas a la NXAPI se realizaron y de dónde provienen.

Solución de problemas de interconexión

Descripción general de la API de Interconnect

La API de Interconnect configura las conexiones externas para una celda del centro de datos de GDC. Existen 3 tipos de interconexiones

Interconexión de centro de datos (DCI): Es la interconexión desde un centro de datos de GDC a otro centro de datos de GDC a través de los conmutadores de hoja perimetrales del plano de datos.
Interconnect de intercambio de tráfico del cliente (CPI): Es la interconexión desde un centro de datos de GDC a la red de ORG a través de los conmutadores 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 perimetrales del plano de datos y los conmutadores de agregación de administración.

Están presentes los siguientes objetos de API:

InterconnectLink: Este objeto de API define los puertos físicos que se conectan a conmutadores externos.
InterconnectAttachment: Este objeto de API define los adjuntos que existen sobre el InterconnectLink configurado. La información que contiene cada 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 pares de BGP de interconexión.

Soluciona problemas

Verifica el estado de InterconnectLink y InterconnectAttachment

Los objetos de 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 para cada puerto físico que se conecta a conmutadores externos.
1. Up: Es información de estado sobre si el puerto está activo o inactivo.
2. DownReason: Es el motivo por el que el puerto está inactivo.
InterconnectAttachment: Se expone la siguiente información para cada uno de los adjuntos de Interconnect configurados.
1. BGPStatus: Es el estado de la sesión de BGP, por ejemplo, Activa o Inactiva.
2. UpTime: Es la marca de tiempo de la última vez que se activó la sesión de BGP.
3. PrefixCounters: Son los contadores que muestran los prefijos totales Received, Sent y Withdrawn.

Verifica las políticas de rutas

RoutePolicy define una lista de prefijos y la acción que se debe realizar, por ejemplo, Permitir o Rechazar. Enumera todas las políticas de rutas asociadas al recurso InterconnectAttachment para verificar si las direcciones IP forman parte de un RoutePolicy válido.

Verifica los prefijos de ruta o el tráfico de BGP en los conmutadores de hoja de borde a través de firewalls

La ruta de datos de interconexión también atraviesa dos firewalls de PANW: el firewall del sistema de detección y prevención de intrusiones (IDPS) y el firewall perimetral. Incluso si los prefijos de ruta se aprenden de la sesión de BGP, es posible que los firewalls los descarten.

Verifica los prefijos de ruta aprendidos en varios `VRFs`

El tráfico externo atraviesa varias VRF en los conmutadores de agregación a medida que transita por los diferentes firewalls. La verificación de los prefijos de ruta de BGP aprendidos a través de estos VRF apunta a los prefijos de ruta o al tráfico descartado en los firewalls.

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

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

oc-vrf
dci-vrf
cp-vrf

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

Accede a los conmutadores de hoja de borde y usa el siguiente comando para mostrar los prefijos de ruta aprendidos en varias VRF:

show bgp vrf <vrf_name> all

Aquí vrf_name puede ser uno de los VRF.

Solución de problemas de BGP de ANG

Archivo kubeconfig del clúster

Asegúrate de tener los siguientes valores de KUBECONFIG_FILE para verificar los objetos:

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

El clúster está atascado en el estado de aprovisionamiento

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, verifica NodePoolClaim y la conectividad del nodo.

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, verifica los objetos NetworkGatewayGroup y BGPPeer.

Verifica 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 establecieron.

No se estableció la sesión de BGP

Verifica `EBGPNeighbor` en `TORSwitchInternal`

Verifica ClusterBGPRouter para obtener el conmutador TOR interconectado de cada interfaz.

Las interfaces de ORG_NAME ClusterBGPRouter se usan para establecer la conexión entre 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

Para cada TORSwitchInternal, verifica spec.ebgpNeighbors para ver si todos los objetos ClusterBGPPeer están configurados.

Depura sesiones de BGP en conmutadores TOR

Establece una conexión SSH con uno de los conmutadores TOR interconectados.

Verifica los vecinos de 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
  ...

Verifica el estado de la sesión de BGP:

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

Consulta los registros de BGP:

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

Para depurar el movimiento con bash, haz lo siguiente:

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

Solución de problemas de redes Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.