Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Diseño e implementación de multiconexión de un sistema final conectado a Ethernet

Para obtener una descripción general de la multiconexión de un sistema final conectado a Ethernet en este diseño de referencia, consulte la sección Compatibilidad de multiconexión para sistemas finales conectados a Ethernet en Componentes de arquitectura de blueprint de estructura de centro de datos.

La figura 1 ilustra el sistema final conectado a Ethernet de host múltiple en este procedimiento:

Figura 1: Descripción general del ejemplo de multiconexión conectada a Ethernet Ethernet-Connected Multihoming Example Overview

Configuración de un sistema final conectado a Ethernet de multihost mediante multiconexión EVPN con enlace troncal VLAN

La multiconexión EVPN se utiliza en este bloque de creación para conectar un sistema final conectado a Ethernet a la red superpuesta. La multiconexión de EVPN funciona al tratar dos o más vínculos físicos multihost como un único segmento de Ethernet identificado por un ID de segmento Ethernet (ESI) de EVPN. El conjunto de vínculos físicos que pertenecen al mismo segmento Ethernet se tratan como una interfaz Ethernet agregada. Los vínculos de miembro, al igual que los vínculos de miembro en una interfaz Ethernet agregada tradicional, proporcionan rutas redundantes hacia y desde el sistema final, al tiempo que garantizan que el tráfico de red superpuesto tenga un equilibrio de carga en las múltiples rutas.

LACP con el modo de temporizador rápido se utiliza para mejorar la detección de fallas y la desactivación de los miembros deteriorados de un segmento de Ethernet. MicroBFD también se puede usar para mejorar aún más el aislamiento de fallas, pero es posible que no se escale para admitir todos los puertos orientados hacia el sistema final. Además, el soporte para microBFD debe existir en el sistema final.

El diseño de referencia probó que un servidor conectado a Ethernet estaba conectado a una sola hoja o multihost a dispositivos de 2 o 3 hojas para verificar que el tráfico se puede manejar correctamente en configuraciones multihost con más de 2 dispositivos hoja; en la práctica, un servidor conectado a Ethernet puede ser multihost a una gran cantidad de dispositivos leaf.

Para configurar un servidor conectado a Ethernet de multiconexión:

  1. (Solo interfaces Ethernet agregadas) Cree las interfaces Ethernet agregadas para conectar cada dispositivo leaf al servidor. Active LACP con un intervalo de período rápido para cada interfaz Ethernet agregada.

    Hoja 10:

    Hoja 11:

    Hoja 12:

    Nota:

    Los tres dispositivos leaf de este paso utilizan el mismo nombre de interfaz Ethernet agregado (ae11) y las mismas interfaces de vínculo miembro (et-0/0/13 y et-0/0/14) para organizar y simplificar la administración de la red.

    Evite usar nombres de AE diferentes en cada VTEP para el mismo ESI, ya que esto requerirá configurar la clave de administración de LACP para que el sistema final pueda identificar los enlaces multihost como parte del mismo LAG.
  2. Configure cada interfaz en una interfaz troncal. Asigne VLAN a cada interfaz troncal.
    Nota:

    Si va a conectar el sistema final al dispositivo leaf con un solo vínculo, reemplace el nombre de interfaz (por ejemplo, ae11—por un nombre de interfaz física—por ejemplo, et-0/0/13—para el resto de este procedimiento.

    Hoja 10:

    Hoja 11:

    Hoja 12:

  3. Configure los vínculos de host múltiple con una ESI.

    Asigne cada interfaz de host múltiple al segmento Ethernet (que se identifica mediante el identificador de segmento Ethernet (ESI), que aloja el servidor conectado a Ethernet. Asegúrese de que el tráfico pasa por todos los vínculos de host múltiple configurando cada vínculo como all-active.

    Los valores de ESI deben coincidir en todas las interfaces de host múltiple.

    Hoja 10 :

    Hoja 11:

    Hoja 12:

  4. Habilite LACP y configure un identificador del sistema.

    El identificador del sistema LACP debe coincidir en todas las interfaces de host múltiple.

    Hoja 10:

    Hoja 11:

    Hoja 12:

  5. Después de confirmar la configuración, compruebe que los vínculos de cada conmutador leaf estén en el Up estado

    Ejemplo:

  6. Compruebe que LACP esté operativo en los vínculos de host múltiple.

Habilitación del control de tormentas

El control de tormentas se puede habilitar como parte de este bloque de construcción. El control de tormentas se usa para prevenir tormentas de tráfico de BUM supervisando los niveles de tráfico de BUM y tomando una acción especificada para limitar el reenvío de tráfico de BUM cuando se excede un nivel de tráfico especificado, denominado nivel de control de tormentas. Consulte Descripción del control de tormentas para obtener información adicional sobre la función.

En este diseño de referencia, el control de tormentas está habilitado en interfaces Ethernet agregadas orientadas al servidor para limitar la velocidad del tráfico de difusión, unidifusión desconocida y multidifusión (BUM). Si la cantidad de tráfico de BUM supera el 1 % del ancho de banda disponible en la interfaz Ethernet agregada, el control de tormentas reduce el tráfico de BUM para evitar tormentas de difusión.

Para habilitar el control de tormentas:

  1. Cree el perfil de control de tormentas que se utilizará para habilitar la característica. Las interfaces que se configuran mediante el perfil de control de tormentas se especifican en este paso.

    Dispositivo Leaf:

  2. Establezca la configuración de control de tormentas dentro del perfil.

    En este diseño de referencia, el control de tormentas se configura para reducir estratégicamente el tráfico de BUM cuando la cantidad de tráfico de BUM supera el 1 % de todo el ancho de banda de interfaz disponible.

    Nota:

    Eliminar el tráfico de BUM es la única acción de control de tormentas admitida en la arquitectura de Cloud Data Center.
    Nota:

    La configuración de control de tormentas de esta versión del diseño de referencia elimina el tráfico de multidifusión que supera el umbral de control de tormentas configurado. Si su red admite aplicaciones basadas en multidifusión, considere la posibilidad de usar una configuración de control de tormentas (como la no-multicast opción de la storm-control-profiles instrucción) que no esté representada en este diseño de referencia.

    Los ajustes de control de tormentas compatibles con aplicaciones basadas en multidifusión se incluirán en una versión futura de este diseño de referencia.
  3. Para verificar la actividad de control de tormentas, ingrese el comando para filtrar los mensajes de registro del sistema relacionados con el control de show log messages | match storm tormentas.

Multiconexión de un sistema final conectado a Ethernet: historial de versiones

La Tabla 1 proporciona un historial de todas las características de esta sección y su compatibilidad dentro de este diseño de referencia.

Tabla 1: Historial de versiones

Lanzamiento

Descripción

19,1 R2

Los conmutadores QFX10002-60C y QFX5120-32C que ejecutan Junos OS versión 19.1R2 y versiones posteriores en el mismo tren de versiones admiten todas las funciones documentadas en esta sección.

18,4R2

Los conmutadores QFX5120-48Y que ejecutan Junos OS versión 18.4R2 y versiones posteriores del mismo tren de versiones admiten todas las funciones documentadas en esta sección.

18.1R3-S3

QFX5110 conmutadores que ejecutan Junos OS versión 18.1R3-S3 y versiones posteriores del mismo tren de versiones admiten todas las funciones documentadas en esta sección.

17,3R3-S1

Todos los dispositivos del diseño de referencia compatibles con la versión 17.3R3-S1 de Junos OS y versiones posteriores del mismo tren de versiones también admiten todas las funciones documentadas en esta sección.

Documentación relacionada