Configurar balanceadores de carga agrupados con BGP

En este documento se describe cómo configurar y usar balanceadores de carga agrupados con el protocolo de puerta de enlace de frontera (BGP) para Google Distributed Cloud. Este modo de balanceo de carga admite la publicación de ServiceType LoadBalancer direcciones IP virtuales (VIPs) a través del protocolo de puerta de enlace de frontera externo (eBGP) para tus clústeres. En este caso, tu red de clústeres es un sistema autónomo que se interconecta con otro sistema autónomo, una red externa, mediante el peering.

Los balanceadores de carga agrupados con capacidad BGP se aplican a todos los tipos de clústeres, pero los clústeres de administrador solo admiten la parte de balanceo de carga del plano de control de esta función.

Usar la función de balanceadores de carga agrupados con BGP ofrece las siguientes ventajas:

  • Usa la función de equilibrio de carga activo/activo de N formas, lo que proporciona una conmutación por error más rápida y un uso más eficiente del ancho de banda disponible.
  • Admite el protocolo de capa 3 que funciona con routers y conmutadores de terceros de la parte superior del rack (ToR) compatibles con eBGP.
  • Permite que los centros de datos que ejecutan una pila de redes definidas por software (SDN) avanzada lleven el límite de la capa 3 hasta los clústeres.

Cómo funciona el balanceo de carga agrupado con BGP

En las siguientes secciones se ofrece un breve resumen de cómo funcionan los balanceadores de carga agrupados con BGP.

Emparejamiento de BGP

La función de balanceadores de carga agrupados con BGP inicia varias conexiones BGP con tu infraestructura. BGP tiene los siguientes requisitos técnicos:

  • Las sesiones de peering son independientes para la IP virtual del plano de control y para las IPs virtuales de los servicios.
  • Las sesiones de peering del plano de control se inician desde las direcciones IP de los nodos del plano de control.
  • Las sesiones de emparejamiento de servicios se inician desde direcciones IP flotantes que especifiques en el NetworkGatewayGroup recurso personalizado.
  • La pasarela de red del controlador de GDC gestiona las direcciones IP flotantes.
  • El balanceo de carga agrupado basado en BGP solo admite el peering eBGP.
  • El emparejamiento de varios saltos se admite de forma predeterminada.
  • No se admiten contraseñas MD5 en sesiones BGP.
  • No se admiten sesiones de emparejamiento basadas en IPv6.
  • Se espera que las rutas anunciadas a cualquier peer se redistribuyan por toda la red y se pueda acceder a ellas desde cualquier otro lugar del clúster.
  • Se recomienda usar la función ADD-PATH de BGP en el modo de recepción para las sesiones de peerings.
  • Si se anuncian varias rutas desde cada peer, se consigue un equilibrio de carga activo/activo.
  • El enrutamiento multipath de igual coste (ECMP) debe estar habilitado en tu red para que se puedan usar varias rutas para distribuir el tráfico entre un conjunto de nodos de balanceador de carga.

Balanceo de carga del plano de control

Cada nodo del plano de control de tu clúster establece sesiones de BGP con uno o varios peers de tu infraestructura. Requerimos que cada nodo del plano de control tenga al menos un peer. En el archivo de configuración del clúster, puedes configurar a qué nodos del plano de control se conectan los peers externos.

En el siguiente diagrama se muestra un ejemplo de peering del plano de control. El clúster tiene dos nodos del plano de control en una subred y uno en otra. Hay un peer externo (TOR) en cada subred y los nodos del plano de control de Google Distributed Cloud se comunican con su TOR.

Balanceo de carga de servicios con el peering de BGP

Balanceo de carga de servicios

Además de las sesiones de emparejamiento que se inician desde cada nodo del plano de control para el emparejamiento del plano de control, se inician sesiones de emparejamiento adicionales para los servicios de LoadBalancer. Estas sesiones de peer no se inician directamente desde las direcciones IP de los nodos del clúster, sino que utilizan direcciones IP flotantes.

Se admiten los servicios con una política de red de externalTrafficPolicy=Local. Sin embargo, el ajuste externalTrafficPolicy=Local depende de la carga de trabajo y hace que las rutas se actualicen cada vez que se añade o se elimina por completo un pod que respalda el servicio de un nodo. Este comportamiento de actualización de rutas puede provocar que el enrutamiento de rutas múltiples de igual coste (ECMP) cambie los flujos de tráfico, lo que puede provocar caídas en el tráfico.

Habilitar direcciones IP flotantes

Para balancear la carga de los servicios, debes reservar direcciones IP flotantes en las subredes de los nodos del clúster para usarlas en el emparejamiento BGP. Se requiere al menos una dirección IP flotante para el clúster, pero te recomendamos que reserves al menos dos direcciones para asegurar la alta disponibilidad de las sesiones BGP. Las direcciones IP flotantes se especifican en el recurso personalizado (CR) NetworkGatewayGroup, que se puede incluir en el archivo de configuración del clúster.

Las direcciones IP flotantes eliminan la preocupación de asignar direcciones IP de altavoces BGP a nodos. La pasarela de red del controlador de GDC se encarga de asignar la NetworkGatewayGroup a los nodos y también gestiona las direcciones IP flotantes. Si un nodo deja de funcionar, la pasarela de red del controlador de GDC reasigna las direcciones IP flotantes para asegurarse de que los peers externos tengan una dirección IP determinista con la que comunicarse.

Peers externos

Para el balanceo de carga del plano de datos, puedes usar los mismos peers externos que se especificaron para el peering del plano de control en la sección loadBalancer.controlPlaneBGP del archivo de configuración del clúster. También puedes especificar diferentes peers de BGP.

Si quiere especificar distintos peers de BGP para el peering del plano de datos, añada las especificaciones de recursos BGPLoadBalancer y BGPPeer al archivo de configuración del clúster. Si no especifica estos recursos personalizados, los peers del plano de control se usarán automáticamente en el plano de datos.

Especifica los peers externos que se usan en las sesiones de emparejamiento con las direcciones IP flotantes en el recurso personalizado BGPPeer, que añades al archivo de configuración del clúster. El recurso BGPPeer incluye una etiqueta para identificarlo por el recurso personalizado BGPLoadBalancer correspondiente. Para seleccionar el BGPPeer que quieras usar, especifica la etiqueta de coincidencia en el campo peerSelector del recurso personalizado BGPLoadBalancer.

La pasarela de red del controlador de GDC intenta establecer sesiones (el número de sesiones se puede configurar) con cada peer externo del conjunto de direcciones IP flotantes reservadas. Te recomendamos que especifiques al menos dos peers externos para asegurar la alta disponibilidad de las sesiones BGP. Cada peer externo designado para el balanceo de carga de Servicios debe configurarse para que se empareje con cada dirección IP flotante especificada en el recurso personalizado NetworkGatewayGroup.

Nodos de balanceador de carga

Se usa un subconjunto de nodos del clúster para el balanceo de carga, lo que significa que son los nodos que se anuncian para poder aceptar el tráfico de balanceo de carga entrante. De forma predeterminada, este conjunto de nodos pertenece al grupo de nodos del plano de control, pero puedes especificar otro grupo de nodos en la sección loadBalancer del archivo de configuración del clúster. Si especificas un grupo de nodos, se usará para los nodos del balanceador de carga en lugar del grupo de nodos del plano de control.

Las direcciones IP flotantes, que funcionan como altavoces BGP, pueden ejecutarse o no en los nodos del balanceador de carga. Las direcciones IP flotantes se asignan a un nodo de la misma subred y el peering se inicia desde ahí, independientemente de si se trata de un nodo de balanceador de carga. Sin embargo, los saltos siguientes anunciados a través de BGP siempre son los nodos del balanceador de carga.

Topología de interconexión de ejemplo

En el siguiente diagrama se muestra un ejemplo de balanceo de carga de servicios con emparejamiento BGP. Hay dos direcciones IP flotantes asignadas a los nodos de sus respectivas subredes. Hay dos peers externos definidos. Cada IP flotante se empareja con ambos peers externos.

Balanceo de carga de servicios con el peering de BGP

Configurar el balanceador de carga BGP

En las siguientes secciones se describe cómo configurar los clústeres y la red externa para usar el balanceador de carga agrupado con BGP.

Planificar la integración con una infraestructura externa

Para usar el balanceador de carga agrupado con BGP, debes configurar la infraestructura externa:

  • La infraestructura externa debe configurarse para que se empareje con cada uno de los nodos del plano de control del clúster para configurar la comunicación del plano de control. Estas sesiones de emparejamiento se usan para anunciar las IPs virtuales del plano de control de Kubernetes.

  • La infraestructura externa debe configurarse para que se comunique con un conjunto de direcciones IP flotantes reservadas para la comunicación del plano de datos. Las direcciones IP flotantes se usan para el emparejamiento BGP de las IPs virtuales de servicio. Te recomendamos que uses dos direcciones IP flotantes y dos peers para asegurar la alta disponibilidad de las sesiones BGP. El proceso para reservar una IP flotante se describe en la sección sobre configurar el clúster para el balanceo de carga agrupado con BGP.

Cuando hayas configurado la infraestructura, añade la información de emparejamiento BGP al archivo de configuración del clúster. El clúster que crees puede iniciar sesiones de emparejamiento con la infraestructura externa.

Configurar un clúster para el balanceo de carga agrupado con BGP

Puedes habilitar y configurar el balanceo de carga agrupado con BGP en el archivo de configuración del clúster al crear un clúster. En el archivo de configuración del clúster, habilita la red avanzada y actualiza la sección loadBalancer. También añade especificaciones para los tres recursos personalizados siguientes:

  • NetworkGatewayGroup: especifica las direcciones IP flotantes que se utilizan en las sesiones de emparejamiento BGP de los servicios.

  • BGPLoadBalancer: especifica con selectores de etiquetas qué peers se usan para el balanceo de carga de BGP.

  • BGPPeer: especifica los peers individuales, incluida una etiqueta para fines de selección, de las sesiones de peering de BGP.

En las siguientes instrucciones se describe cómo configurar el clúster y los tres recursos personalizados para configurar el balanceo de carga agrupado con BGP.

  1. Añade el campo advancedNetworking al archivo de configuración del clúster en la sección clusterNetwork y asígnale el valor true.

    Este campo habilita la función de redes avanzadas, concretamente el recurso NetworkGatewayGroup.

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: CLUSTER_NAMESPACE
spec:
...
  clusterNetwork:
    advancedNetworking: true

    Sustituye CLUSTER_NAMESPACE por el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres de clúster de Google Distributed Cloud son el nombre del clúster con el prefijo cluster-. Por ejemplo, si le pones el nombre test al clúster, el espacio de nombres será cluster-test.

  2. En la sección loadBalancer del archivo de configuración del clúster, asigna el valor bundled a mode y añade un campo type con el valor bgp.

    Estos valores de campo permiten el balanceo de carga agrupado basado en BGP.

    ...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp
    ...

  3. Para especificar la información de emparejamiento BGP del plano de control, añade los siguientes campos a la sección loadBalancer:

        ...
    # AS number for the cluster
    localASN: CLUSTER_ASN

    # List of BGP peers used for the control plane peering sessions.
    bgpPeers:
    - ip: PEER_IP
      asn: PEER_ASN
      # optional; if not specified, all CP nodes connect to all peers.
      controlPlaneNodes:   # optional
      - CP_NODE_IP
...

    Haz los cambios siguientes:

    • CLUSTER_ASN: el número de sistema autónomo del clúster que se está creando.
    • PEER_IP: la dirección IP del dispositivo externo.
    • PEER_ASN: el número de sistema autónomo de la red que contiene el dispositivo externo.
    • CP_NODE_IP: (opcional) la dirección IP del nodo del plano de control que se conecta al peer externo. Si no especificas ningún nodo del plano de control, todos los nodos del plano de control podrán conectarse al peer externo. Si especifica una o varias direcciones IP, solo los nodos especificados participarán en las sesiones de emparejamiento.

    Puedes especificar varios peers externos. bgpPeers toma una lista de asignaciones. Te recomendamos que especifiques al menos dos peers externos para que las sesiones BGP tengan una alta disponibilidad. Para ver un ejemplo con varios peers, consulta Ejemplos de configuraciones.

  4. Define los campos loadBalancer.ports, loadBalancer.vips y loadBalancer.addressPools (se muestran los valores predeterminados).

    ...
  loadBalancer:
  ...
    # Other existing load balancer options remain the same
    ports:
      controlPlaneLBPort: 443
    # When type=bgp, the VIPs are advertised over BGP
    vips:
      controlPlaneVIP: 10.0.0.8
      ingressVIP: 10.0.0.1

    addressPools:
    - name: pool1
      addresses:
      - 10.0.0.1-10.0.0.4
...

  5. Especifica el nodo de clúster que se va a usar para equilibrar la carga del plano de datos.

    Este paso es opcional. Si no descomenta la sección nodePoolSpec, los nodos del plano de control se usarán para el balanceo de carga del plano de datos.

    ...
  # Node pool used for load balancing data plane (nodes where incoming traffic
  # arrives. If not specified, this defaults to the control plane node pool.
  # nodePoolSpec:
  #   nodes:
  #   - address: <Machine 1 IP>
...

  6. Reserva direcciones IP flotantes configurando el recurso personalizado NetworkGatewayGroup:

    Las direcciones IP flotantes se usan en sesiones de emparejamiento para equilibrar la carga del plano de datos.

    ...
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
  nodeSelector:    # optional
  - NODE_SELECTOR
...

    Haz los cambios siguientes:

    • CLUSTER_NAMESPACE: el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres de clúster de Google Distributed Cloud son el nombre del clúster precedido por cluster-. Por ejemplo, si le pones el nombre test al clúster, el espacio de nombres será cluster-test.
    • FLOATING_IP: una dirección IP de una de las subredes del clúster. Debe especificar al menos una dirección IP, pero le recomendamos que especifique al menos dos.
    • NODE_SELECTOR: (opcional) un selector de etiquetas para identificar los nodos con los que se van a crear instancias de sesiones de peerings con peers externos, como los conmutadores de la parte superior del rack (ToR). Si no es necesario, quita este campo.

    Asegúrate de que el recurso personalizado NetworkGatewayGroup se llame default y use el espacio de nombres del clúster. Para ver un ejemplo de cómo podría ser la especificación de recursos personalizados NetworkGatewayGroup, consulta Ejemplos de configuraciones.

  7. (Opcional) Especifica los peers que se van a usar para el balanceo de carga del plano de datos configurando el recurso personalizado BGPLoadBalancer:

    ...
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  peerSelector:
    PEER_LABEL: "true"
...

    Haz los cambios siguientes:

    • CLUSTER_NAMESPACE: el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres de clúster de Google Distributed Cloud son el nombre del clúster precedido por cluster-. Por ejemplo, si le pones el nombre test al clúster, el espacio de nombres será cluster-test.
    • PEER_LABEL: etiqueta que se usa para identificar los peers que se van a usar para el balanceo de carga. Cualquier recurso personalizado BGPPeer con una etiqueta coincidente especifica los detalles de cada elemento del mismo nivel.

    Asegúrate de que el recurso personalizado BGPLoadBalancer se llama default y usa el espacio de nombres del clúster. Si no especifica un BGPLoadBalancer recurso personalizado, los peers del plano de control se utilizan automáticamente para el balanceo de carga del plano de datos. Para ver ejemplos detallados, consulta Configuraciones de ejemplo.

  8. (Opcional) Especifica los peers externos del plano de datos configurando uno o varios recursos personalizados BGPPeer:

    ...
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: BGP_PEER_NAME
  namespace: CLUSTER_NAMESPACE
  labels:
    PEER_LABEL: "true"
spec:
  localASN: CLUSTER_ASN
  peerASN: PEER_ASN
  peerIP: PEER_IP
  sessions: SESSION_QTY
  selectors:   # Optional
    gatewayRefs:
    - GATEWAY_REF
  ...

    Haz los cambios siguientes:

    • BGP_PEER_NAME: el nombre del elemento del mismo nivel.
    • CLUSTER_NAMESPACE: el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres de clúster de Google Distributed Cloud son el nombre del clúster precedido por cluster-. Por ejemplo, si le pones el nombre test al clúster, el espacio de nombres será cluster-test.
    • PEER_LABEL: etiqueta que se usa para identificar los peers que se van a usar para el balanceo de carga. Esta etiqueta debe corresponderse con la etiqueta especificada en el recurso personalizado BGPLoadBalancer.
    • CLUSTER_ASN: el número de sistema autónomo del clúster que se está creando.
    • PEER_IP: la dirección IP del dispositivo externo. Te recomendamos que especifiques al menos dos peers externos, pero debes especificar al menos uno.
    • PEER_ASN: el número de sistema autónomo de la red que contiene el dispositivo externo.
    • SESSION_QTY: número de sesiones que se van a establecer para este peer. Te recomendamos que establezcas al menos dos sesiones para asegurarte de que mantienes una conexión con el peer en caso de que uno de tus nodos deje de funcionar.
    • GATEWAY_REF: (opcional) nombre de un recurso NetworkGatewayGroup que se va a usar para el peering. Si no se define ningún valor, se podrán usar todos los recursos de pasarela. Usa este ajuste junto con el campo nodeSelector del recurso NetworkGatewayGroups para seleccionar los nodos que se usarán en el peering con un peer externo específico, como un switch ToR. Puede introducir varias entradas para seleccionar varios NetworkGatewayGroups, si quiere, con el formato de una pasarela por línea.

    Puedes especificar varios peers externos creando recursos personalizados BGPPeer adicionales. Te recomendamos que especifiques al menos dos peers externos (dos recursos personalizados) para que las sesiones BGP tengan alta disponibilidad. Si no especificas un recurso personalizado BGPPeer, los peers del plano de control se usarán automáticamente para el balanceo de carga del plano de datos.

  9. Cuando ejecutas bmctl cluster create para crear el clúster, se realizan comprobaciones preparatorias. Entre otras comprobaciones, las comprobaciones previas validan la configuración del peering de BGP del plano de control e informan de cualquier problema directamente a la estación de trabajo del administrador antes de que se pueda crear el clúster.

    Si se completa correctamente, los recursos de balanceo de carga de BGP añadidos (NetworkGatewayGroup, BGPLoadBalancer y BGPPeer) se incluirán en el clúster de administración del espacio de nombres del clúster de usuario. Usa el archivo kubeconfig del clúster de administrador cuando hagas actualizaciones posteriores de estos recursos. A continuación, el clúster de administrador reconcilia los cambios en el clúster de usuario. Si editas estos recursos directamente en el clúster de usuarios, el clúster de administrador sobrescribirá los cambios en las reconciliaciones posteriores.

Te recomendamos que utilices la función ADD-PATH de BGP para las sesiones de emparejamiento, tal como se especifica en el RFC 7911. De forma predeterminada, el protocolo BGP solo permite anunciar un único salto siguiente a los peers para un solo prefijo. BGP ADD-PATH permite anunciar varios saltos siguientes para el mismo prefijo. Cuando se usa ADD-PATH con el balanceo de carga agrupado basado en BGP, el clúster puede anunciar varios nodos de clúster como nodos de frontend (saltos siguientes) para un servicio de balanceador de carga (prefijo). Habilita ECMP en la red para que el tráfico se pueda distribuir por varias rutas. La capacidad de distribuir el tráfico anunciando varios nodos de clúster como saltos siguientes mejora la escalabilidad de la capacidad del plano de datos para el balanceo de carga.

Si tu dispositivo externo del mismo nivel, como un switch o un router ToR (top-of-rack), admite BGP ADD-PATH, basta con activar solo la extensión de recepción. El balanceo de carga agrupado con BGP funciona sin la función ADD-PATH, pero la restricción de anunciar un solo nodo de balanceo de carga por sesión de emparejamiento limita la capacidad del plano de datos del balanceador de carga. Sin ADD-PATH, Google Distributed Cloud elige nodos para anunciarse desde el grupo de nodos del balanceador de carga e intenta distribuir los próximos saltos de diferentes IPs virtuales entre distintos nodos.

Restringir el emparejamiento BGP a los nodos del balanceador de carga

Google Distributed Cloud asigna automáticamente direcciones IP flotantes en cualquier nodo de la misma subred que la dirección IP flotante. Las sesiones de BGP se inician desde estas direcciones IP aunque no lleguen a los nodos del balanceador de carga. Este comportamiento es intencionado, ya que hemos desacoplado el plano de control (BGP) del plano de datos (grupos de nodos de balanceo de carga).

Si quiere restringir el conjunto de nodos que se pueden usar para el peering de BGP, puede designar una subred para que se use solo en los nodos del balanceador de carga. Es decir, puedes configurar todos los nodos de esa subred para que estén en el grupo de nodos del balanceador de carga. Después, cuando configures las direcciones IP flotantes que se usan para el emparejamiento de BGP, asegúrate de que sean de la misma subred. Google Distributed Cloud se asegura de que las asignaciones de direcciones IP flotantes y el peering de BGP se realicen solo desde los nodos del balanceador de carga.

Configurar el balanceo de carga de BGP con redes de doble pila

A partir de la versión 1.14.0 de Google Distributed Cloud, el balanceador de carga agrupado basado en BGP admite IPv6. Con la introducción de la compatibilidad con IPv6, puedes configurar servicios LoadBalancer de IPv6 y de pila dual en un clúster configurado para redes de pila dual. En esta sección se describen los cambios necesarios para configurar el balanceo de carga agrupado con BGP de pila dual.

Para habilitar los servicios LoadBalancer de pila dual, es necesario hacer los siguientes cambios en la configuración:

  • El clúster subyacente debe estar configurado para redes de doble pila:

    • Especifica los CIDRs de servicio IPv4 e IPv6 en el archivo de configuración del clúster en spec.clusterNetwork.services.cidrBlocks.

    • Define los recursos ClusterCIDRConfig adecuados para especificar los intervalos de CIDR de IPv4 e IPv6 de los pods.

    Para obtener más información sobre cómo configurar un clúster para la red de doble pila, consulta Red de doble pila IPv4/IPv6.

  • Especifica un grupo de direcciones IPv6 en el archivo de configuración del clúster en spec.loadBalancer.addressPools. Para que MetalLB asigne direcciones IP a un servicio de pila dual, debe haber al menos un grupo de direcciones que tenga direcciones en formato IPv4 e IPv6.

En el siguiente ejemplo de configuración se destacan los cambios necesarios para el balanceo de carga agrupado de doble pila con BGP:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  clusterNetwork:
  services:
      cidrBlocks:
      # Dual-stack Service IP addresses must be provided
      - 10.96.0.0/16
      - fd00::/112
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

    addressPools:
    - name: pool1
      addresses:
      # Each address must be either in the CIDR form (1.2.3.0/24)
      # or range form (1.2.3.1-1.2.3.5).
      - "203.0.113.1-203.0.113.20"
      - "2001:db8::1-2001:db8::20"  # Note the additional IPv6 range

... # Other cluster config info omitted
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-bm
spec:
  ipv4:
    cidr: "192.168.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "2001:db8:1::/112"
    perNodeMaskSize: 120

Limitaciones del balanceo de carga agrupado de doble pila con BGP

Cuando configures tu clúster para que use el balanceo de carga agrupado de doble pila con BGP, ten en cuenta las siguientes limitaciones:

  • No se admite el balanceo de carga del plano de control IPv6.

  • Las sesiones de BGP IPv6 no se admiten, pero las rutas IPv6 se pueden anunciar a través de sesiones IPv4 mediante BGP multiprotocolo.

Configuraciones de ejemplo

En las siguientes secciones se muestra cómo configurar el balanceo de carga basado en BGP para diferentes opciones o comportamientos.

Configurar todos los nodos para que usen los mismos peers

Como se muestra en el siguiente diagrama, esta configuración da como resultado un conjunto de peers externos (10.8.0.10 y 10.8.0.11) a los que pueden acceder todos los nodos. Los nodos del plano de control (10.0.1.10, 10.0.1.11 y 10.0.2.10) y las direcciones IP flotantes (10.0.1.100 y 10.0.2.100) asignadas a los nodos del plano de datos pueden acceder a los peers.

Se puede acceder a los mismos peers externos mediante cualquiera de las direcciones IP flotantes (10.0.1.100 o 10.0.2.100) reservadas para el peering de loadBalancerServices. Las direcciones IP flotantes se pueden asignar a nodos que estén en la misma subred.

Balanceo de carga de BGP en el que todos los nodos usan los mismos peers

Como se muestra en el siguiente ejemplo de configuración de clúster, puede configurar los peers de los nodos del plano de control, bgpPeers, sin especificar controlPlaneNodes. Si no se especifica ningún nodo para los peers, todos los nodos del plano de control se conectan a todos los peers.

Especifica las direcciones IP flotantes que se van a usar en las sesiones de emparejamiento de balanceo de carga de los servicios en el recurso personalizado NetworkGatewayGroup. En este ejemplo, como no se especifica ningún BGPLoadBalancer, los peers del plano de control se utilizan automáticamente para las sesiones BGP del plano de datos.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

Configurar nodos de plano de control específicos para que se comuniquen con peers externos específicos

Como se muestra en el siguiente diagrama, esta configuración da como resultado dos nodos de plano de control (10.0.1.10 y 10.0.1.11) que se emparejan con un peer externo (10.0.1.254). El tercer nodo de plano de control (10.0.2.10) se empareja con otro peer externo (10.0.2.254). Esta configuración es útil cuando no quieres que todos los nodos se conecten a todos los peers. Por ejemplo, puede que quieras que los nodos del plano de control se comuniquen únicamente con los switches de la parte superior del rack (ToR) correspondientes.

Se puede acceder a los mismos peers externos mediante cualquiera de las direcciones IP flotantes (10.0.1.100 o 10.0.2.100) reservadas para las sesiones de emparejamiento de balanceo de carga de Services. Las direcciones IP flotantes se pueden asignar a nodos que estén en la misma subred.

Balanceo de carga de BGP con asignación explícita de nodos del plano de control a peers

Como se muestra en el siguiente ejemplo de configuración de clúster, puedes restringir los nodos del plano de control que pueden conectarse a un peer determinado especificando sus direcciones IP en el campo controlPlaneNodes del peer en la sección bgpPeers.

Especifica las direcciones IP flotantes que se van a usar en las sesiones de emparejamiento de balanceo de carga de los servicios en el recurso personalizado NetworkGatewayGroup. En este ejemplo, como no se especifica ningún BGPLoadBalancer, los peers del plano de control se utilizan automáticamente para las sesiones BGP del plano de datos.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.10

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

Configurar el plano de control y el plano de datos por separado

Como se muestra en el siguiente diagrama, esta configuración da como resultado dos nodos del plano de control (10.0.1.10 y 10.0.1.11) emparejados con un peer externo (10.0.1.254) y el tercer nodo del plano de control (10.0.2.11) emparejado con otro peer externo (10.0.2.254).

Se puede acceder a un tercer peer externo (10.0.3.254) mediante cualquiera de las direcciones IP flotantes (10.0.3.100 o 10.0.3.101) reservadas para las sesiones de peering de balanceo de carga de servicios. Las direcciones IP flotantes se pueden asignar a nodos que estén en la misma subred.

Balanceo de carga de BGP con configuración independiente para el plano de control y el plano de datos

Como se muestra en el siguiente ejemplo de configuración de clúster, puedes restringir los nodos del plano de control que pueden conectarse a un peer determinado especificando sus direcciones IP en el campo controlPlaneNodes del peer en la sección bgpPeers.

Especifica las direcciones IP flotantes que se van a usar en las sesiones de emparejamiento de balanceo de carga de los servicios en el recurso personalizado NetworkGatewayGroup.

Para configurar el balanceo de carga del plano de datos, sigue estos pasos:

  • Especifica el peer externo del plano de datos en el recurso BGPPeer y añade una etiqueta para seleccionar el peer, como cluster.baremetal.gke.io/default-peer: "true".

  • Especifica la etiqueta correspondiente al campo peerSelector del recurso BGPLoadBalancer.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.11

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

Modificar la configuración del balanceo de carga basado en BGP

Una vez que hayas creado el clúster configurado para usar el balanceo de carga agrupado con BGP, podrás actualizar algunos ajustes de configuración, pero no todos, después de crear el clúster.

Usa el archivo kubeconfig del clúster de administrador cuando hagas actualizaciones posteriores a los recursos relacionados con BGP (NetworkGatewayGroup, BGPLoadBalancer y BGPPeer). A continuación, el clúster de administrador reconcilia los cambios en el clúster de usuario. Si editas estos recursos directamente en el clúster de usuarios, el clúster de administrador sobrescribirá los cambios en las reconciliaciones posteriores.

Plano de control

La información de emparejamiento BGP del plano de control se puede actualizar en el recurso Cluster. Puede añadir o quitar los peers especificados en la sección de balanceo de carga del plano de control.

En las siguientes secciones se describen las prácticas recomendadas para actualizar la información de emparejamiento BGP del plano de control.

Comprobar el estado del peer antes de actualizar

Para minimizar el riesgo de configurar incorrectamente los peers, compruebe que las sesiones de peering de BGP del plano de control tengan el estado esperado antes de hacer cambios. Por ejemplo, si espera que todas las sesiones de emparejamiento BGP estén activas, compruebe que todos los pods bgp-advertiser informen de ready, lo que indica que las sesiones están activas. Si el estado actual no coincide con lo que esperas, soluciona el problema antes de actualizar la configuración del otro.

Para obtener información sobre cómo recuperar los detalles de las sesiones de BGP del plano de control, consulta Sesiones de BGP del plano de control.

Actualizar los peers de forma controlada

Actualiza los peers de uno en uno, si es posible, para aislar los posibles problemas:

  1. Añadir o actualizar un solo peer.
  2. Espera a que se reconcilie la configuración.
  3. Verifica que el clúster pueda conectarse al peer nuevo o actualizado.
  4. Quita los elementos antiguos o innecesarios.

Servicios

Para actualizar los grupos de direcciones y la configuración de los nodos del balanceador de carga, edita nodePoolSpec en el recurso Cluster.

Para modificar la configuración del peering de BGP después de crear el clúster, edita los recursos personalizados NetworkGatewayGroup y BGPLoadBalancer. Las modificaciones que se hagan en la información de emparejamiento de estos recursos personalizados se reflejarán en la configuración de la solución de balanceo de carga del clúster de destino.

Haz los cambios en los recursos de origen del espacio de nombres del clúster solo en el clúster de administración. Se sobrescribirán todas las modificaciones que se hayan hecho en los recursos del clúster de destino (usuario).

Solución de problemas

En las siguientes secciones se describe cómo acceder a la información para solucionar problemas del balanceo de carga agrupado con BGP.

Sesiones de BGP del plano de control

La configuración del emparejamiento BGP del plano de control se valida con comprobaciones previas durante la creación del clúster. Las comprobaciones preparatorias intentan hacer lo siguiente:

  • Establece una conexión BGP con cada peer.
  • Anuncia la IP virtual del plano de control.
  • Verifica que se puede acceder al nodo del plano de control mediante la IP virtual.

Si la creación del clúster no supera las comprobaciones de solicitudes preparatorias, revisa los registros de comprobaciones de solicitudes preparatorias para ver si hay errores. Los archivos de registro de comprobación previa con marca de fecha se encuentran en el directorio baremetal/bmctl-workspace/CLUSTER_NAME/log.

En el tiempo de ejecución, los altavoces BGP del plano de control se ejecutan como pods estáticos en cada nodo del plano de control y escriben información de eventos en los registros. Estos pods estáticos incluyen "bgpadvertiser" en su nombre, por lo que debes usar el siguiente comando kubectl get pods para ver el estado de los pods de altavoz BGP:

kubectl -n kube-system get pods | grep bgpadvertiser

Cuando los pods funcionan correctamente, la respuesta tiene un aspecto similar al siguiente:

bgpadvertiser-node-01                            1/1     Running   1          167m
bgpadvertiser-node-02                            1/1     Running   1          165m
bgpadvertiser-node-03                            1/1     Running   1          163m

Usa el siguiente comando para ver los registros del pod bgpadvertiser-node-01:

kubectl -n kube-system logs bgpadvertiser-node-01

Sesiones de BGP de servicios

El recurso BGPSession proporciona información sobre las sesiones de BGP actuales. Para obtener información sobre una sesión, primero debes obtener las sesiones actuales y, a continuación, recuperar el recurso BGPSession de una de las sesiones.

Usa el siguiente comando kubectl get para enumerar las sesiones actuales:

kubectl -n kube-system get bgpsessions

El comando devuelve una lista de sesiones como la del siguiente ejemplo:

NAME                 LOCAL ASN   PEER ASN   LOCAL IP     PEER IP      STATE            LAST REPORT
10.0.1.254-node-01   65500       65000      10.0.1.178   10.0.1.254   Established      2s
10.0.1.254-node-02   65500       65000      10.0.3.212   10.0.1.254   Established      2s
10.0.3.254-node-01   65500       65000      10.0.1.178   10.0.3.254   Established      2s
10.0.3.254-node-02   65500       65000      10.0.3.212   10.0.3.254   Established      2s

Usa el siguiente comando kubectl describe para obtener el recurso BGPSession de la sesión de BGP 10.0.1.254-node-01:

kubectl -n kube-system describe bgpsession 10.0.1.254-node-01

El recurso BGPSession devuelto debería tener un aspecto similar al siguiente ejemplo:

Name:         10.0.1.254-node-01
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         BGPSession
Metadata:
 (omitted)
Spec:
  Floating IP:  10.0.1.178
  Local ASN:    65500
  Local IP:     10.0.1.178
  Node Name:    node-01
  Peer ASN:     65000
  Peer IP:      10.0.1.254
Status:
  Advertised Routes:
    10.0.4.1/32
  Last Report Time:  2021-06-14T22:09:36Z
  State:             Established

Usa el comando kubectl get para obtener los recursos de BGPAdvertisedRoute:

kubectl -n kube-system get bgpadvertisedroutes

La respuesta, que debería ser similar al siguiente ejemplo, muestra las rutas que se están anunciando:

NAME                                    PREFIX           METRIC
default-default-load-balancer-example   10.1.1.34/32
default-gke-system-istio-ingress        10.1.1.107/32

Usa kubectl describe para ver detalles sobre los siguientes saltos que anuncia cada ruta.

Recuperar el acceso a la IP virtual del plano de control de clústeres autogestionados

Para recuperar el acceso al VIP del plano de control en un clúster de administrador, híbrido o independiente, debes actualizar la configuración de BGP en el clúster. Como se muestra en el siguiente ejemplo de comando, usa SSH para conectarte al nodo y, a continuación, usa kubectl para abrir el recurso de clúster y editarlo.

ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP

kubectl --kubeconfig /etc/kubernetes/admin.conf edit -n CLUSTER_NAMESPACE cluster CLUSTER_NAME

Haz los cambios siguientes:

  • IDENTITY_FILE: el nombre del archivo de identidad SSH que contiene la clave de identidad para la autenticación con clave pública.
  • CLUSTER_NODE_IP: la dirección IP del nodo del clúster.
  • CLUSTER_NAMESPACE: el espacio de nombres del clúster.
  • CLUSTER_NAME: el nombre del clúster.

Modifica la configuración del peering de BGP en el objeto de clúster. Después de guardar la nueva configuración del clúster, monitoriza el estado de los pods bgpadvertiser. Si la configuración funciona, los pods se reinician y se ponen en buen estado una vez que se conectan a sus iguales.

Verificación manual de BGP

En esta sección se incluyen instrucciones para verificar manualmente la configuración de BGP. El procedimiento configura una conexión BGP de larga duración para que puedas depurar aún más la configuración de BGP con tu equipo de red. Sigue este procedimiento para verificar tu configuración antes de crear un clúster o si las comprobaciones de solicitudes preparatorias relacionadas con BGP fallan.

Las comprobaciones preparatorias automatizan las siguientes tareas de verificación de BGP:

  • Configura una conexión BGP con un par.
  • Anuncia la IP virtual del plano de control.
  • Verifica que el tráfico enviado desde todos los demás nodos del clúster a la IP virtual llegue al nodo del balanceador de carga actual.

Estas tareas se ejecutan para cada peer de BGP en cada nodo del plano de control. Es fundamental superar estas comprobaciones al crear un clúster. Sin embargo, las comprobaciones previas no crean conexiones de larga duración, por lo que es difícil depurar un error.

En las siguientes secciones se ofrecen instrucciones para configurar una conexión BGP y anunciar una ruta desde una sola máquina de clúster a un peer. Para probar varias máquinas y varios peers, repite las instrucciones con otra combinación de máquina y peer.

Recuerda que las conexiones BGP se establecen desde los nodos del plano de control, así que asegúrate de probar este procedimiento desde uno de los nodos del plano de control que tengas previsto.

Obtener el archivo binario del programa de pruebas de BGP

Sigue los pasos de esta sección en tu estación de trabajo de administrador. Estos pasos obtienen el programa bgpadvertiser, que se usa para probar las conexiones BGP, y lo copian en los nodos del plano de control en los que quieras hacer las pruebas.

  1. Extrae la imagen de Docker de ansible-runner.

    Sin réplica de registro

    Si no usas un mirror de registro, ejecuta los siguientes comandos para extraer la imagen de Docker de ansible-runner:

    gcloud auth login
gcloud auth configure-docker
docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Con réplica de registro

    Si usas un mirror de registro, ejecuta los siguientes comandos para descargar la imagen de Docker de ansible-runner:

    docker login REGISTRY_HOST
docker pull REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Sustituye REGISTRY_HOST por el nombre de tu servidor de réplica del registro.

  2. Para extraer el archivo binario bgpadvertiser.

    Sin réplica de registro

    Para extraer el archivo binario bgpadvertiser, ejecuta el siguiente comando:

    docker cp $(docker create gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

    Con réplica de registro

    Para extraer el archivo binario bgpadvertiser, ejecuta el siguiente comando:

    docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

  3. Para copiar el archivo binario bgpadvertiser en el nodo del plano de control con el que quieras hacer la prueba, ejecuta el siguiente comando:

    scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/

    Haz los cambios siguientes:

    • USERNAME: el nombre de usuario que usas para acceder al nodo del plano de control.

    • CP_NODE_IP: la dirección IP del nodo del plano de control.

Configurar una conexión BGP

Sigue los pasos de esta sección en un nodo del plano de control.

  1. Crea un archivo de configuración en el nodo /tmp/bgpadvertiser.conf que tenga el siguiente aspecto:

    localIP: NODE_IP
localASN: CLUSTER_ASN
peers:
- peerIP: PEER_IP
  peerASN: PEER_ASN

    Haz los cambios siguientes:

    • NODE_IP: dirección IP del nodo del plano de control en el que te encuentras.
    • CLUSTER_ASN: el número de sistema autónomo que usa el clúster.
    • PEER_IP: la dirección IP de uno de los peers externos que quieras probar.
    • PEER_ASN: el número de sistema autónomo de la red que contiene el dispositivo externo.

  2. Ejecuta el daemon bgpadvertiser y sustituye la IP virtual del plano de control en el siguiente comando:

    /tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIP

    Sustituye CONTROL_PLANE_VIP por la dirección IP que vas a usar para el VIP de tu plano de control. Este comando hace que el anunciante de BGP anuncie esta dirección al peer.

  3. Consulta el resultado del programa.

    En este punto, se inicia el daemon bgpadvertiser, intenta conectarse al peer y anuncia la VIP. El programa imprime periódicamente mensajes (consulta el siguiente ejemplo de salida) que incluyen BGP_FSM_ESTABLISHED cuando se establece la conexión BGP.

    {"level":"info","ts":1646788815.5588224,"logger":"BGPSpeaker","msg":"GoBGP gRPC debug endpoint disabled","localIP":"21.0.101.64"}
{"level":"info","ts":1646788815.5596201,"logger":"BGPSpeaker","msg":"Started.","localIP":"21.0.101.64"}
I0309 01:20:15.559667 1320826 main.go:154] BGP advertiser started.
I0309 01:20:15.561434 1320826 main.go:170] Health status HTTP server started at "127.0.0.1:8080".
INFO[0000] Add a peer configuration for:21.0.101.80      Topic=Peer
{"level":"info","ts":1646788815.5623345,"logger":"BGPSpeaker","msg":"Peer added.","localIP":"21.0.101.64","peer":"21.0.101.80/4273481989"}
DEBU[0000] IdleHoldTimer expired                         Duration=0 Key=21.0.101.80 Topic=Peer
I0309 01:20:15.563503 1320826 main.go:187] Peer applied: {4273481989 21.0.101.80}
DEBU[0000] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ACTIVE old=BGP_FSM_IDLE reason=idle-hold-timer-expired
DEBU[0000] create Destination                            Nlri=10.0.0.1/32 Topic=Table
{"level":"info","ts":1646788815.5670514,"logger":"BGPSpeaker","msg":"Route added.","localIP":"21.0.101.64","route":{"ID":0,"Metric":0,"NextHop":"21.0.101.64","Prefix":"10.0.0.1/32","VRF":""}}
I0309 01:20:15.568029 1320826 main.go:199] Route added: {0 0 21.0.101.64 10.0.0.1/32 }
I0309 01:20:15.568073 1320826 main.go:201] BGP advertiser serving...
DEBU[0005] try to connect                                Key=21.0.101.80 Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENSENT old=BGP_FSM_ACTIVE reason=new-connection
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENCONFIRM old=BGP_FSM_OPENSENT reason=open-msg-received
INFO[0005] Peer Up                                       Key=21.0.101.80 State=BGP_FSM_OPENCONFIRM Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ESTABLISHED old=BGP_FSM_OPENCONFIRM reason=open-msg-negotiated
DEBU[0005] sent update                                   Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer attributes="[{Origin: i} 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] received update                               Key=21.0.101.80 Topic=Peer attributes="[{Origin: i} 4273481989 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] create Destination                            Nlri=10.0.0.1/32 Topic=Table
DEBU[0035] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"
DEBU[0065] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"

Si no ves estos mensajes, vuelve a comprobar los parámetros de configuración de BGP en el archivo de configuración y verifica con el administrador de la red. Ahora tienes una conexión BGP configurada. Puedes verificar con el administrador de la red que vea la conexión establecida en su lado y que vea la ruta anunciada.

Prueba de tráfico

Para comprobar que la red puede reenviar tráfico a la IP virtual, debes añadir la IP virtual al nodo del plano de control que esté ejecutando bgpadvertiser. Ejecuta el siguiente comando en otro terminal para que bgpadvertiser siga funcionando:

  1. Añade la IP virtual al nodo del plano de control:

    ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME

    Haz los cambios siguientes:

    • CONTROL_PLANE_VIP: el argumento VIP --advertise-ip de bgpadvertiser.
    • INTF_NAME: la interfaz de Kubernetes en el nodo. Es decir, la interfaz que tiene la dirección IP que has introducido en la configuración de Google Distributed Cloud para loadBalancer.bgpPeers.controlPlaneNodes.

  2. Hacer ping a la IP virtual desde otro nodo:

    ping CONTROL_PLANE_VIP

    Si el ping no se realiza correctamente, puede que haya un problema con la configuración de BGP en el dispositivo de red. Colabora con tu administrador de red para verificar la configuración y resolver el problema.

Limpieza

Sigue estos pasos para restablecer el nodo después de haber verificado manualmente que BGP funciona. Si no restableces el nodo correctamente, la configuración manual puede interferir con la comprobación previa o con la creación posterior del clúster.

  1. Elimina la IP virtual del nodo del plano de control si la has añadido para la prueba de tráfico:

    ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME

  2. En el nodo del plano de control, pulsa Ctrl+C en la terminal bgpadvertiser para detener bgpadvertiser.

  3. Verifica que no se esté ejecutando ningún proceso bgpadvertiser:

    ps -ef | grep bgpadvertiser

  4. Si ves procesos en ejecución, detenlos con el comando kill.