Configura balanceadores de cargas agrupados con BGP

Version 1.13 

• Más reciente
• Versión 1.16
• Versiones anteriores (no admitidas)

En este documento, se describe cómo configurar y usar los balanceadores de cargas en paquetes con el protocolo de puerta de enlace fronteriza (BGP) para clústeres de Anthos en equipos físicos. Este modo de balanceo de cargas admite el anuncio de direcciones IP virtuales (VIP) ServiceType LoadBalancer a través del protocolo de puerta de enlace fronteriza externa (eBGP) para tus clústeres. En esta situación, la red de tu clúster es un sistema autónomo, que se interconecta con otro sistema autónomo, una red externa, a través del intercambio de tráfico.

Los balanceadores de cargas en paquetes con capacidad de BGP se aplican a todos los tipos de clústeres, pero los clústeres de administrador solo admiten la parte del balanceo de cargas del plano de control de esta capacidad.

El uso de balanceadores de cargas en paquetes con la función de BGP proporciona los siguientes beneficios:

• Usa la capacidad de balanceo de cargas activo/activo de N-way, 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 switches top-of-rack (ToR) de terceros que son compatibles con eBGP.
• Habilita los centros de datos que ejecutan una pila de red definida por software (SDN) avanzada para empujar el límite de la Capa 3 hasta los clústeres.

Cómo funciona el balanceo de cargas en paquetes con BGP

En las siguientes secciones, se proporciona un resumen rápido del funcionamiento de los balanceadores de cargas en paquetes con BGP.

Intercambio de tráfico de BGP

Los balanceadores de cargas en paquetes con la función de BGP inicia varias conexiones de BGP a tu infraestructura. BGP tiene los siguientes requisitos técnicos:

• Las sesiones de intercambio de tráfico son independientes para las VIP del plano de control y las del servicio.
• Las sesiones de intercambio de tráfico del plano de control se inician desde las direcciones IP de los nodos del plano de control.
• Las sesiones de intercambio de tráfico de servicio se inician a partir de las direcciones IP flotantes que especifiques en el recurso personalizado de NetworkGatewayGroup.
• El controlador de puerta de enlace de red de Anthos administra las direcciones IP flotantes.
• El balanceo de cargas en paquetes basado en BGP solo es compatible con el intercambio de tráfico eBGP.
• El intercambio de tráfico entre saltos es compatible de forma predeterminada.
• Las contraseñas MD5 en sesiones de BGP no son compatibles.
• Las sesiones de intercambio de tráfico basadas en IPv6 no son compatibles.
• Se espera que las rutas anunciadas a cualquier intercambio de tráfico se redistribuyan en toda la red y se pueda acceder a ellas desde cualquier otro lugar del clúster.
• Se recomienda el uso de la capacidad ADD-PATH de BGP en el modo de recepción para las sesiones de intercambio de tráfico.
• Anunciar varias rutas de acceso de cada intercambio de tráfico genera un balanceo de cargas activo/activo.
• El enrutamiento de varias rutas de igual costo (ECMP) debe estar habilitado para tu red a fin de que se puedan usar varias rutas para distribuir el tráfico entre un conjunto de nodos del balanceador de cargas.

Balanceo de cargas del plano de control

Cada nodo del plano de control en tu clúster establece sesiones de BGP con uno o más intercambios de tráfico en tu infraestructura. Necesitamos que cada nodo del plano de control tenga al menos un intercambio de tráfico. En el archivo de configuración del clúster, puedes configurar qué nodos del plano de control se conectan a qué intercambios de tráfico externos.

En el siguiente diagrama, se muestra un ejemplo del intercambio de tráfico del plano de control. El clúster tiene dos nodos del plano de control en una subred y uno en otra. Hay un intercambio de tráfico externo (TOR) en cada subred y los clústeres de Anthos en los nodos del plano de control de equipos físicos intercambian tráfico con el TOR.

Nota: En el diagrama, se ilustra solo un ejemplo. No es necesario que los intercambios de tráfico estén en la misma subred. Habilitamos BGP con salto múltiple de forma predeterminada.

Balanceo de cargas de servicios

Además de las sesiones de intercambio de tráfico que se inician desde cada nodo del plano de control para este intercambio de tráfico del plano de control, se inician sesiones de intercambio de tráfico adicionales para los servicios LoadBalancer. Estas sesiones de intercambio de tráfico no se inician directamente desde las direcciones IP de nodo del clúster, sino que usan direcciones IP flotantes.

Nota: El balanceo de cargas de servicios (o plano de datos) no se aplica a los clústeres de administrador. Si incluyes información de configuración de la sesión de BGP para el plano de datos en tu clúster de administrador, se ignora la configuración.

No se admiten los servicios con una política de red externalTrafficPolicy=Local.

Direcciones IP flotantes

El balanceo de cargas de servicios requiere que reserves direcciones IP flotantes en las subredes del nodo del clúster para usar en el intercambio de tráfico de BGP. Se requiere al menos una dirección IP flotante para el clúster, pero te recomendamos reservar al menos dos direcciones a fin de garantizar una alta disponibilidad para las sesiones de BGP. Las direcciones IP flotantes se especifican en el recurso personalizado de (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 interlocutores de BGP a los nodos. El controlador de la puerta de enlace de red de Anthos se encarga de asignar NetworkGatewayGroup a los nodos y también administra las direcciones IP flotantes. Si un nodo falla, el controlador de la puerta de enlace de red de Anthos reasigna las direcciones IP flotantes para garantizar que los pares externos tengan una dirección IP determinista con la que intercambiar tráfico.

Intercambios de tráfico externos

Para el balanceo de cargas del plano de datos, puedes usar los mismos pares externos que se especificaron en el intercambio de tráfico del plano de control en la sección loadBalancer.controlPlaneBGP del archivo de configuración del clúster. Como alternativa, puedes especificar diferentes pares de BGP.

Si deseas especificar diferentes pares de BGP para el intercambio de tráfico del plano de datos, agrega las especificaciones de recursos BGPLoadBalancer y BGPPeer al archivo de configuración del clúster. Si no especificas estos recursos personalizados, los pares del plano de control se usan de forma automática para el plano de datos.

Debes especificar los pares externos que se usan para sesiones de intercambio de tráfico con las direcciones IP flotantes en el recurso personalizado BGPPeer, que debes agregar al archivo de configuración del clúster. El recurso BGPPeer incluye una etiqueta para la identificación del recurso personalizado BGPLoadBalancer correspondiente. Debes especificar la etiqueta coincidente en el campo peerSelector del recurso personalizado BGPLoadBalancer para seleccionar el BGPPeer que usarás.

El controlador de Anthos Network Gateway intenta establecer sesiones (la cantidad de sesiones se puede configurar) para cada par externo desde el conjunto de direcciones IP flotantes reservadas. Te recomendamos que especifiques al menos dos pares externos a fin de garantizar una alta disponibilidad para las sesiones de BGP. Cada par externo designado para el balanceo de cargas de servicios debe configurarse de modo que intercambie tráfico con cada dirección IP flotante especificada en el recurso personalizado NetworkGatewayGroup.

Nodos del balanceador de cargas

Se usa un subconjunto de nodos para el balanceo de cargas, lo que significa que son los nodos que se anuncian a fin de aceptar el tráfico de balanceo de cargas entrante. Este conjunto de nodos se establece de forma predeterminada en el grupo de nodos del plano de control, pero puedes especificar un grupo de nodos diferente en la sección loadBalancer del archivo de configuración del clúster. Si especificas un grupo de nodos, se usa para los nodos del balanceador de cargas, en lugar del grupo de nodos del plano de control.

Las direcciones IP flotantes, que funcionan como interlocutores de BGP, pueden o no ejecutarse en los nodos del balanceador de cargas. Las direcciones IP flotantes se asignan a un nodo en la misma subred y el intercambio de tráfico se inicia desde allí, sin importar si es un nodo del balanceador de cargas. Sin embargo, los saltos siguientes que se anuncian a través de BGP siempre son los nodos del balanceador de cargas.

Topología de intercambio de tráfico de ejemplo

En el siguiente diagrama, se muestra un ejemplo de balanceo de cargas de servicio con intercambio de tráfico de BGP. Hay dos direcciones IP flotantes asignadas a nodos en sus respectivas subredes. Hay dos pares externos definidos. Cada IP flotante intercambia tráfico con ambos pares externos.

Configura el balanceador de cargas de BGP

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

Planifica tu integración con infraestructura externa

Para usar el balanceador de cargas en paquetes con BGP, debes configurar la infraestructura externa:

• La infraestructura externa se debe configurar para intercambiar tráfico con cada uno de los nodos del plano de control en el clúster a fin de configurar la comunicación del plano de control. Estas sesiones de intercambio de tráfico se usan para anunciar las VIP del plano de control de Kubernetes.

• La infraestructura externa debe configurarse para intercambiar tráfico con un conjunto de direcciones IP flotantes reservadas para la comunicación del plano de datos. Las direcciones IP flotantes se usan para el intercambio de tráfico de BGP en las VIP del servicio. Te recomendamos usar dos direcciones IP flotantes y dos pares a fin de garantizar una alta disponibilidad para sesiones de BGP. El proceso de reserva de una IP flotante se describe como parte de la configuración del clúster para el balanceo de cargas en paquetes con BGP.

Una vez que hayas configurado la infraestructura, agrega la información de intercambio de tráfico de BGP al archivo de configuración del clúster. El clúster que creas puede iniciar sesiones de intercambio de tráfico con la infraestructura externa.

Configura tu clúster para el balanceo de cargas en paquetes con BGP

Puedes habilitar y configurar el balanceo de cargas en paquetes con BGP en el archivo de configuración del clúster cuando creas un clúster. En el archivo de configuración del clúster, debes habilitar las Herramientas de redes avanzadas y actualizar la sección loadBalancer. También debes agregar especificaciones para estos tres recursos personalizados:

• NetworkGatewayGroup: Especifica las direcciones IP flotantes que se usan para las sesiones de intercambio de tráfico de BGP de servicios.

• BGPLoadBalancer: Especifica con selectores de etiquetas qué pares se usan para el balanceo de cargas de BGP.

• BGPPeer: Especifica los pares individuales, incluida una etiqueta que permite su selección, para sesiones de intercambio de tráfico de BGP.

En las siguientes instrucciones, se describe cómo configurar tu clúster y los tres recursos personalizados para configurar el balanceo de cargas en paquetes con BGP.

1. Agrega el campo advancedNetworking al archivo de configuración del clúster en la sección clusterNetwork y configúralo como true.

   Este campo habilita la capacidad de Herramientas de redes avanzadas, en particular, el recurso de Network Gateway Group.

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

   Reemplaza CLUSTER_NAMESPACE por el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres de los clústeres de Anthos en equipos físicos son el nombre del clúster precedido por cluster-. Por ejemplo, si le asignas el nombre test al clúster, el espacio de nombres es cluster-test.

2. En la sección loadBalancer del archivo de configuración del clúster, configura mode como bundled y agrega un campo type con el valor bgp.

   Estos valores de campo permiten el balanceo de cargas en paquetes 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 intercambio de tráfico de BGP para el plano de control, agrega 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
   ...
   

   Reemplaza lo siguiente:

   • CLUSTER_ASN: el número del sistema autónomo para el clúster que se crea.
   • PEER_IP: Es la dirección IP del dispositivo de intercambio de tráfico externo.
   • PEER_ASN: El número del sistema autónomo para la red que contiene el dispositivo de intercambio de tráfico externo.
   • CP_NODE_IP: es la dirección IP del nodo del plano de control que se conecta al par externo (opcional). Si no especificas ningún nodo del plano de control, todos los nodos del plano de control pueden conectarse al par externo. Si especificas una o más direcciones IP, solo los nodos especificados participan en las sesiones de intercambio de tráfico.

   Puedes especificar varios intercambios de tráfico externos, bgpPeers toma una lista de asignaciones. Te recomendamos que especifiques al menos dos intercambios de tráfico externos para la alta disponibilidad de las sesiones de BGP. Para ver un ejemplo con varios intercambios de tráfico, consulta Ejemplos de configuración.

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

   Nota: Cuando usas el balanceo de cargas basado en BGP (mode: bundled y type: bgp), las VIP que especificas no deben provenir de la misma subred que cualquiera de los nodos del clúster.

   ...
     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 del clúster que se usará para balancear las cargas del plano de datos.

   Este paso es opcional. Si no quitas el comentario de la sección nodePoolSpec, los nodos del plano de control se usan para el balanceo de cargas 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 mediante la configuración del recurso personalizado NetworkGatewayGroup:

   Las direcciones IP flotantes se usan en las sesiones de intercambio de tráfico para el balanceo de cargas del plano de datos.

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

   Reemplaza lo siguiente:

   • CLUSTER_NAMESPACE: es el espacio de nombres para el clúster. De forma predeterminada, los espacios de nombres de los clústeres de Anthos en equipos físicos son el nombre del clúster precedido por cluster-. Por ejemplo, si le asignas el nombre test al clúster, el espacio de nombres es cluster-test.
   • FLOATING_IP: es una dirección IP de una de las subredes del clúster. Debes especificar al menos una dirección IP, pero te recomendamos que especifiques al menos dos direcciones IP.

   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 verse la especificación del recurso personalizado NetworkGatewayGroup, consulta Configuraciones de ejemplo.

7. (Opcional) Especifica los pares que se usarán para el balanceo de cargas del plano de datos mediante la configuración del recurso personalizado BGPLoadBalancer:

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

   Reemplaza lo siguiente:

   • CLUSTER_NAMESPACE es el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres de los clústeres de Anthos en equipos físicos son el nombre del clúster precedido por cluster-. Por ejemplo, si le asignas el nombre test al clúster, el espacio de nombres es cluster-test.
   • PEER_LABEL: es la etiqueta que se usa para identificar qué pares usar en el balanceo de cargas. Cualquier recurso personalizado BGPPeer con una etiqueta coincidente especifica los detalles de cada par.

   Asegúrate de que el recurso personalizado BGPLoadBalancer se llame default y use el espacio de nombres del clúster. Si no especificas un recurso personalizado BGPLoadBalancer, los pares del plano de control se usan de forma automática para el balanceo de cargas del plano de datos. Para ver ejemplos completos, consulta Configuraciones de ejemplo.

8. (Opcional) Especifica los pares externos para el plano de datos mediante la configuración de uno o más 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
     ...
   

   Reemplaza lo siguiente:

   • BGP_PEER_NAME es el nombre del par.
   • CLUSTER_NAMESPACE: es el espacio de nombres para el clúster. De forma predeterminada, los espacios de nombres de los clústeres de Anthos en equipos físicos son el nombre del clúster precedido por cluster-. Por ejemplo, si le asignas el nombre test al clúster, el espacio de nombres es cluster-test.
   • PEER_LABEL: es la etiqueta que se usa para identificar qué pares usar en el balanceo de cargas. Esta etiqueta debe corresponder con la etiqueta especificada en el recurso personalizado BGPLoadBalancer.
   • CLUSTER_ASN: el número del sistema autónomo para el clúster que se crea.
   • PEER_IP: Es la dirección IP del dispositivo de intercambio de tráfico externo. Te recomendamos que especifiques al menos dos pares externos, pero debes especificar al menos uno.
   • PEER_ASN: El número del sistema autónomo para la red que contiene el dispositivo de intercambio de tráfico externo.
   • SESSION_QTY es la cantidad de sesiones que se establecerán para este par. Te recomendamos que establezcas al menos dos sesiones para asegurarte de mantener una conexión con el par en caso de que uno de tus nodos se desconecte.

   Puedes especificar varios pares externos mediante la creación de recursos personalizados BGPPeer adicionales. Te recomendamos que especifiques al menos dos pares externos (dos recursos personalizados) para una alta disponibilidad de las sesiones de BGP. Si no especificas un recurso personalizado BGPPeer, los pares del plano de control se usan de forma automática para el balanceo de cargas del plano de datos.

9. Cuando ejecutas bmctl cluster create para crear tu clúster, se ejecutan las comprobaciones previas. Entre otras comprobaciones, las comprobaciones previas validan la configuración del intercambio de tráfico de BGP para el plano de control y, luego, informan cualquier problema directamente a la estación de trabajo de administrador antes de que se pueda crear el clúster.

   Cuando el proceso finaliza con éxito, los recursos agregados de balanceo de cargas de BGP (NetworkGatewayGroup, BGPLoadBalancer y BGPPeer) se agregan al clúster de administrador en el espacio de nombres del clúster de usuario. Usa el archivo kubeconfig del clúster de administrador cuando realices actualizaciones posteriores en estos recursos. Luego, el clúster de administrador concilia los cambios en el clúster de usuario. Si editas estos recursos directamente en el clúster de usuario, el clúster de administrador reemplaza tus cambios en las conciliaciones posteriores.

Te recomendamos que uses la capacidad ADD-PATH de BGP para las sesiones de intercambio de tráfico, como se especifica en RFC 7911. De forma predeterminada, el protocolo BGP permite que solo se anuncie un siguiente salto a los pares para un solo prefijo. El ADD-PATH de BGP permite anunciar varios saltos siguientes para el mismo prefijo. Cuando ADD-PATH se usa con el balanceo de cargas en paquetes basado en BGP, el clúster puede anunciar varios nodos del clúster como nodos de frontend (saltos siguientes) para un servicio de balanceador de cargas (prefijo). Habilita ECMP en la red para que el tráfico pueda distribuirse a través de varias rutas. La capacidad de fan-out del tráfico mediante la publicidad de varios nodos del clúster como siguientes saltos proporciona un escalamiento mejorado de la capacidad del plano de datos para el balanceo de cargas.

Si el dispositivo de intercambio de tráfico externo, como un switch o router top-of-rack (ToR) admite BGP ADD-PATH, solo es suficiente activar la extensión de recepción. El balanceo de cargas en paquetes con BGP funciona sin la capacidad ADD-PATH, pero la restricción de anunciar un solo nodo de balanceo de cargas por sesión de intercambio de tráfico limita la capacidad del plano de datos del balanceador de cargas. Sin ADD-PATH, los clústeres de Anthos en equipos físicos eligen nodos para anunciar desde el grupo de nodos del balanceador de cargas e intentan distribuir los saltos siguientes para diferentes VIP en diferentes nodos.

Restringe el intercambio de tráfico de BGP a los nodos del balanceador de cargas

Los clústeres de Anthos alojados en equipos físicos asignan de forma automática 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, incluso si no llegan a los nodos del balanceador de cargas. Este comportamiento es de diseño porque desacoplamos el plano de control (BGP) del plano de datos (grupos de nodos de LB).

Si deseas restringir el conjunto de nodos que pueden usarse para el intercambio de tráfico de BGP, puedes designar una subred que se usará solo para los nodos del balanceador de cargas. Es decir, puedes configurar todos los nodos de esa subred en el grupo de nodos del balanceador de cargas. Luego, cuando configures las direcciones IP flotantes que se usan para el intercambio de tráfico de BGP, asegúrate de que provengan de esta misma subred. Los clústeres de Anthos en equipos físicos garantizan que las asignaciones de direcciones IP flotantes y el intercambio de tráfico de BGP se realicen solo desde los nodos del balanceador de cargas.

Configuración de ejemplo

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

Configura todos los nodos para que usen los mismos intercambios de tráfico

Como se muestra en el siguiente diagrama, esta configuración da como resultado un conjunto de intercambios de tráfico 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 llegan a los intercambios de tráfico.

Se puede acceder a los mismos intercambios de tráfico externos mediante las direcciones IP flotantes (10.0.1.100 o 10.0.2.100) que se reservan para el intercambio de tráfico de servicios loadBalancer. Las direcciones IP flotantes se pueden asignar a nodos que están en la misma subred.

Como se muestra en la siguiente muestra de configuración del clúster, configuras los intercambios de tráfico para los nodos del plano de control, bgpPeers, sin especificar controlPlaneNodes. Cuando no se especifican nodos para los intercambios de tráfico, todos los nodos del plano de control se conectan a todos los intercambios de tráfico.

Especifica las direcciones IP flotantes que se usarán para las sesiones de intercambio de tráfico de balanceo de cargas de los servicios en el recurso personalizado NetworkGatewayGroup. En este ejemplo, como no se especifica BGPLoadBalancer, los pares del plano de control se usan de forma automática para las sesiones de BGP del plano de datos.

Nota: Se quitaron las secciones de configuración del clúster que no se aplican a esta configuración de balanceo de cargas basada en BGP para que la muestra sea más fácil de leer.

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

Configura nodos de plano de control específicos para que intercambien tráfico con intercambios de tráfico externos específicos

Como se muestra en el siguiente diagrama, esta configuración genera dos nodos del plano de control (10.0.1.10 y 10.0.1.11) intercambien tráfico con un par externo (10.0.1.254). El tercer nodo del plano de control (10.0.2.10) intercambia tráfico con otro par externo (10.0.2.254). Esta configuración es útil cuando no quieres que todos los nodos se conecten a todos los pares. Por ejemplo, es posible que desees que los nodos del plano de control intercambien tráfico solo con los switches top-of-rack (ToR) correspondientes.

Se puede acceder a los mismos pares externos mediante las direcciones IP flotantes (10.0.1.100 o 10.0.2.100) que están reservan para sesiones de intercambio de tráfico de balanceo de cargas de servicios. Las direcciones IP flotantes se pueden asignar a nodos que se encuentran en la misma subred.

Como se muestra en la siguiente muestra de configuración del clúster, debes restringir qué nodos del plano de control pueden conectarse a un intercambio de tráfico determinado si especificas sus direcciones IP en el campo controlPlaneNodes del intercambio de tráfico en la sección bgpPeers.

Especifica las direcciones IP flotantes que se usarán para las sesiones de intercambio de tráfico de balanceo de cargas de los servicios en el recurso personalizado NetworkGatewayGroup. En este ejemplo, como no se especifica BGPLoadBalancer, los pares del plano de control se usan de forma automática para las sesiones de BGP del plano de datos.

Nota: Se quitaron las secciones de configuración del clúster que no se aplican a esta configuración de balanceo de cargas basada en BGP para que la muestra sea más fácil de leer.

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

Configura 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 de plano de control (10.0.1.10 y 10.0.1.11) que intercambian tráfico con un par externo (10.0.1.254) y el tercer nodo del plano de control (10.0.2.10) intercambia tráfico con otro par externo (10.0.2.254).

Se puede acceder a un tercer intercambio de tráfico externo (10.0.3.254) mediante cualquiera de las direcciones IP flotantes (10.0.3.100 o 10.0.3.101) que están reservadas para las sesiones de intercambio de tráfico de balanceo de cargas de servicios. Las direcciones IP flotantes se pueden asignar a nodos que se encuentran en la misma subred.

Como se muestra en la siguiente muestra de configuración del clúster, debes restringir qué nodos del plano de control pueden conectarse a un intercambio de tráfico determinado si especificas sus direcciones IP en el campo controlPlaneNodes del intercambio de tráfico en la sección bgpPeers.

Especifica las direcciones IP flotantes que se usarán para las sesiones de intercambio de tráfico de balanceo de cargas de los servicios en el recurso personalizado NetworkGatewayGroup.

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

• Especifica el par externo para el plano de datos en el recurso BGPPeer y agrega una etiqueta que se use en la selección de pares, como cluster.baremetal.gke.io/default-peer: "true".

• Especifica la etiqueta coincidente para el campo peerSelector en el recurso BGPLoadBalancer.

Nota: Se quitaron las secciones de configuración del clúster que no se aplican a este paquete de configuración de balanceo de cargas basado en BGP para que la muestra sea más fácil de leer.

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

Modifica tu configuración de balanceo de cargas basado en BGP

Después de crear el clúster configurado para usar el balanceo de cargas en paquetes con BGP, se pueden actualizar algunos parámetros de configuración, pero no se pueden actualizar algunos después de la creación del clúster.

Usa el archivo kubeconfig del clúster de administrador cuando realices actualizaciones posteriores en los recursos relacionados con BGP (NetworkGatewayGroup, BGPLoadBalancer y BGPPeer). Luego, el clúster de administrador concilia los cambios en el clúster de usuario. Si editas estos recursos directamente en el clúster de usuario, el clúster de administrador reemplaza tus cambios en las conciliaciones posteriores.

Plano de control

La información de intercambio de tráfico de BGP del plano de control se puede actualizar en el recurso Cluster. Puedes agregar o quitar pares especificados en la sección de balanceo de cargas del plano de control.

Advertencia: Ten cuidado cuando actualices la información de intercambio de tráfico de BGP del plano de control, en especial para los clústeres autoadministrados (clústeres de tipo híbrido, independiente o de administrador). La VIP del plano de control y el plano de control de Kubernetes se vuelven inaccesibles desde fuera del clúster si el clúster no puede anunciar la VIP del plano de control a ninguno de los pares. Por ejemplo, el acceso se pierde si la configuración de intercambio de tráfico no hace referencia a un par válido o si el clúster no puede conectarse al par debido a problemas de configuración o de red. Si deseas obtener instrucciones para recuperar el acceso, consulta Recupera el acceso a la VIP del plano de control para clústeres autoadministrados.

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

Archivo Program.cs antes de la actualización:

Para minimizar el riesgo de configurar de forma incorrecta los pares, verifica que las sesiones de intercambio de tráfico de BGP del plano de control estén en el estado esperado antes de realizar cambios. Por ejemplo, si esperas que todas las sesiones de intercambio de tráfico de BGP estén activas, verifica que todos los Pods bgp-advertiser informen ready, lo que indica que las sesiones están activas. Si el estado actual no coincide con lo que esperabas, soluciona el problema antes de actualizar la configuración de los pares.

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

Actualiza los pares de manera controlada

Si puedes, actualiza un par a la vez para ayudar a aislar los posibles problemas:

1. Agrega o actualiza un solo par.
2. Espera a que la configuración se concilie.
3. Verifica que el clúster pueda conectarse al par nuevo o actualizado.
4. Quita los pares antiguos o innecesarios.

Servicios

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

Advertencia: Ten cuidado cuando actualices la información de intercambio de tráfico para los servicios del plano de datos. Si la información de intercambio de tráfico está mal configurada y el clúster no puede establecer sesiones de BGP para los pares y anunciar las VIP, los clientes no podrán acceder a los servicios a través de las VIP de LoadBalancer. Te recomendamos actualizar la configuración de a un par a la vez, como se describe en la sección anterior, para minimizar el riesgo de ingresar una configuración incorrecta.

Para modificar la configuración de intercambio de tráfico de BGP después de crear el clúster, edita los recursos personalizados NetworkGatewayGroup y BGPLoadBalancer. Cualquier modificación en la información de intercambio de tráfico en estos recursos personalizados se refleja en la configuración de la solución de balanceo de cargas en el clúster de destino.

Realiza actualizaciones en los recursos de origen en el espacio de nombres del clúster solo en el clúster de administrador. Se reemplazan todas las modificaciones realizadas en los recursos del clúster objetivo (usuario).

Soluciona problemas

En las siguientes secciones, se describe cómo acceder a la información de solución de problemas para el balanceo de cargas en paquetes con BGP.

Sesiones de BGP del plano de control

La configuración de intercambio de tráfico de BGP del plano de control se valida con comprobaciones previas durante la creación del clúster. Las comprobaciones previas intentan realizar lo siguiente:

• Establecer una conexión BGP con cada par.
• Anunciar la VIP del plano de control.
• Verificar que se pueda acceder al nodo del plano de control mediante la VIP.

Si la creación de tu clúster falla en las comprobaciones previas, revisa los registros de las comprobaciones previas en busca de errores. Los archivos de registro de comprobaciones previas con marca de fecha se encuentran en el directorio baremetal/bmctl-workspace/CLUSTER_NAME/log.

En el entorno de ejecución, los hablantes de 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 del hablante de BGP:

kubectl -n kube-system get pods | grep bgpadvertiser

Nota: La condición de preparación de los Pods bgpadvertiser del plano de control está vinculada al estado de las sesiones de BGP. Esto significa que un Pod se declara Listo solo cuando todas sus sesiones de BGP están activas. Si una de las sesiones de BGP del Pod falla, la condición de preparación del Pod cambiará a Falso.

Cuando los Pods funcionan de forma correcta, la respuesta se ve de la siguiente manera:

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 la sesión, primero obtén las sesiones actuales y, luego, recupera 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 muestra una lista de sesiones como el siguiente ejemplo:

NAME               LOCAL ASN   PEER ASN   LOCAL IP     PEER IP      STATE            LAST REPORT
bgppeer1-node-03   65500       65000      10.0.1.178   10.0.1.254   Established      2s
bgppeer1-node-05   65500       65000      10.0.3.212   10.0.1.254   Established      2s
bgppeer2-node-03   65500       65000      10.0.1.178   10.0.3.254   Established      2s
bgppeer2-node-05   65500       65000      10.0.3.212   10.0.3.254   Established      2s

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

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

El recurso BGPSession que se muestra debería ser 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 de kubectl get para obtener los recursos BGPAdvertisedRoute:

kubectl -n kube-system get bgpadvertisedroutes

La respuesta, que debería ser similar al siguiente ejemplo, muestra las rutas que se anuncian en este momento:

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 los detalles sobre qué saltos siguientes se anuncian en cada ruta.

Recupera el acceso a la VIP del plano de control para clústeres autoadministrados

Para recuperar el acceso a la VIP del plano de control en un clúster híbrido, independiente o de administrador, debes actualizar la configuración de BGP en el clúster. Como se observa en la siguiente muestra de comandos, usa SSH para conectarte al nodo y, luego, usa kubectl a fin de abrir el recurso del 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

Reemplaza lo siguiente:

• IDENTITY_FILE es el nombre del archivo de identidad SSH que contiene la clave de identidad para la autenticación de clave pública.
• CLUSTER_NODE_IP es 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 de intercambio de tráfico de BGP en el objeto de clúster. Después de guardar la configuración nueva del clúster, supervisa el estado de los Pods bgpadvertiser. Si la configuración funciona, los Pods se reinician y se recuperan una vez que se conectan a sus pares.

Verificación de BGP manual

En esta sección, se incluyen instrucciones para verificar la configuración de BGP de forma manual. El procedimiento configura una conexión de BGP de larga duración para que puedas depurar aún más la configuración de BGP con tu equipo de redes. Usa este procedimiento para verificar la configuración antes de crear un clúster o úsalo si las verificaciones previas relacionadas con BGP fallan.

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

• Configurar una conexión de BGP a un par.
• Anunciar la VIP del plano de control.
• Verificar que el tráfico enviado de todos los demás nodos del clúster a la VIP llegue al nodo del balanceador de cargas actual.

Estas tareas se ejecutan para cada par de BGP en cada nodo del plano de control. Pasar estas verificaciones es fundamental cuando se crea un clúster. Sin embargo, las verificaciones previas no crean conexiones de larga duración, por lo que es difícil depurar una falla.

En las siguientes secciones, se proporcionan instrucciones para configurar una conexión de BGP y anunciar una ruta desde una máquina de un solo clúster a un par. Para probar múltiples máquinas y pares, repite las instrucciones con una combinación diferente de máquina y par.

Recuerda que las conexiones de BGP se establecen desde los nodos del plano de control, por lo que debes asegurarte de probar este procedimiento desde uno de tus nodos planificados del plano de control.

Obtén el objeto binario del programa de prueba de BGP

Ejecuta los pasos que se indican en esta sección en la estación de trabajo del administrador. Con estos pasos, se obtiene el programa bgpadvertiser que se usa para probar las conexiones de BGP y se copia en los nodos del plano de control en los que deseas realizar pruebas.

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

   Sin duplicación de registro

   Si no usas una duplicación 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 duplicación de registro

   Si usas una duplicación del registro, ejecuta los siguientes comandos para extraer 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
   

   Reemplaza REGISTRY_HOST por el nombre de tu servidor de duplicación de registro.

2. Para extraer el objeto binario bgpadvertiser.

   Sin duplicación de registro

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

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

   Con duplicación de registro

   Para extraer el objeto 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 objeto binario bgpadvertiser en el nodo del plano de control con el que deseas realizar pruebas, ejecuta el siguiente comando:

   scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/
   

   Reemplaza lo siguiente:

   • 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.

Configura una conexión de BGP

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

1. Crea un archivo de configuración en el nodo en /tmp/bgpadvertiser.conf que se vea así:

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

   Reemplaza lo siguiente:

   • NODE_IP: Dirección IP del nodo del plano de control en el que te encuentras.
   • CLUSTER_ASN: El número del sistema autónomo que usa el clúster.
   • PEER_IP: La dirección IP de uno de los pares externos que deseas probar.
   • PEER_ASN: El número del sistema autónomo para la red que contiene el dispositivo de intercambio de tráfico externo.

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

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

   Reemplaza CONTROL_PLANE_VIP por la dirección IP que usarás para la VIP del plano de control. Este comando hace que el anunciante de BGP anuncie esta dirección al par.

3. Consulta el resultado del programa.

   En este punto, el daemon bgpadvertiser se inicia, intenta conectarse al par y anuncia la VIP. El programa imprime mensajes de forma periódica (consulta el siguiente resultado de muestra) que incluyen BGP_FSM_ESTABLISHED cuando se establece la conexión de 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 verificar los parámetros de configuración de BGP en el archivo de configuración y verifica con el administrador de red. Ahora tienes configurada una conexión de BGP. Puedes comunicarte con el administrador de red para verificar que ve la conexión establecida en su lado y que ve la ruta anunciada.

Prueba de tráfico

Para probar que la red puede reenviar tráfico a la VIP, debes agregar la VIP al nodo del plano de control que ejecuta bgpadvertiser. Ejecuta el siguiente comando en una terminal diferente para dejar bgpadvertiser en ejecución:

1. Agrega la VIP al nodo del plano de control:

   ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME
   

   Reemplaza lo siguiente:

   • CONTROL_PLANE_VIP: El argumento --advertise-ip de VIP del bgpadvertiser.
   • INTF_NAME: La interfaz de Kubernetes en el nodo. Es decir, la interfaz que tiene la dirección IP que colocas en la configuración de clústeres de Anthos en equipos físicos para loadBalancer.bgpPeers.controlPlaneNodes.

2. Haz ping a la VIP desde un nodo diferente:

   ping CONTROL_PLANE_VIP
   

   Si el ping no tiene éxito, es posible que haya un problema con la configuración de BGP en el dispositivo de red. Trabaja con tu administrador de red para verificar la configuración y resolver el problema.

Limpia

Asegúrate de seguir estos pasos para restablecer el nodo después de verificar de forma manual que BGP funciona. Si no restableces el nodo de forma correcta, la configuración manual puede interferir en la verificación previa o la creación posterior del clúster.

1. Quita la VIP del nodo del plano de control si la agregaste para la prueba de tráfico:

   ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME
   

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

3. Verifica que no haya procesos bgpadvertiser en ejecución:

   ps -ef | grep bgpadvertiser
   

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