Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Replicación asistida

 

En el capítulo EVPN Intra-VLAN Multicast Without Optimization , se han examinado los distintos procedimientos para el reenvío de datos de multidifusión, como la replicación de entrada, el reenvío de DF/ndf y las reglas de diferencia locales.

Normalmente, los centros de datos disponen de varios conmutadores de primer plano (TOR/LEAF) (en el orden de centenares) que tienen menos densidad de puertos, tienen menos capacidad de reenvío o procesamiento y son menos costosos. Por ejemplo, QFX5110 es un dispositivo así y es el adecuado para una función de hoja.

Además, una topología física de centro de datos tiene un Figure 1 aspecto similar a los siguientes componentes:

  • Capa de hoja: Existen varias hojas (QFX 5110s) que se conectan a los hosts de la VM, a los servidores más bajos (BMS), etc.

  • HOJA de borde: Existen dos dispositivos de hojas denominados dispositivos de hoja de borde (BL) (QFX10K) que se utilizan para conectar el tejido de CC con el mundo exterior a través de una puerta de enlace (MX-GW).

  • Lomo eficiente: Hay un par de dispositivos de spine Lean (LS) (QFX10K) que se utilizan para interconectar físicamente los dispositivos de EVPN participantes. Estos dispositivos de spine eficiente solo funcionan como interconexiones físicas, no alojan ninguna interfaz de acceso y generalmente no participan en una superposición de EVPN. Forman parte del BGP subyacente.

Figure 1: Topología típica de centro de datos físico
Topología típica de centro de datos físico

Características y desafíos de la replicación de entrada

Cuando el origen de multidifusión envía tráfico para diferentes flujos, por ejemplo, en el caso de aplicaciones IPTV, el índice de tráfico suele ser muy alto (en orden de 4Mbps por flujo, como son las secuencias HD). Cuando llega el tráfico tan alto en la hoja 1, LEAF-1 debe replicar el tráfico en todos los demás PEs de la estructura. Para lograr esto, para cada paquete hoja 1 que se recibe en la interfaz de acceso, replica una copia en cada PE remoto y la envía a través del núcleo EVPN, Figure 2tal como se muestra en la.

Figure 2: Flujo de tráfico de replicación de entrada en el subyacente
Flujo de tráfico de replicación de entrada en el subyacente

Por ejemplo, 1000 fluye a 4 Mbps por flujo, y alrededor de 200 PEs en la estructura, hoja 1 envía salida (1000 * 200 * 4 Mbps = 800Gbps). En este caso, surgen dos situaciones.

Dado que LEAF-1 es un dispositivo con menos capacidad, se carga para hacer 200 copias (una por cada PE) del flujo de tráfico pesado de Incom. Esto puede fundir potencialmente las Ingress.

Aunque el tráfico de superposición es de 800 Gbps distribuido a 200 PEs, (4 Gbps por PE en la topología lógica), LEAF-1 envía todo el tráfico de 800 Gbps en el vínculo físico entre LEAF-1 y LS-1. A partir de este momento, LS-1 reenvía estos paquetes a cada uno de los demás PEs a 4 Gbps cada uno. El vínculo entre LS-1 y LEAF-3 indica que’s dice, transporta 4Gbps, que es lo que se espera y no es un problema. Sin embargo, el vínculo entre hojas-1 y LS-1 se sobreutilizará gravemente, sin dejar espacio para otras aplicaciones y posibles caídas de tráfico.

Acabamos de ilustrar esta situación con una fuente de multidifusión. Si hay varios orígenes detrás de otras hojas que envían tráfico a tasas altas, muchas hojas serán efectivas, ya que los vínculos que van desde la hoja hasta la LS también se retraerán

Replicación asistida

Mediante el escenario anterior,’Exploremos si existe cualquier cosa que pueda hacer para mitigar los problemas de (i) la incapacidad de la hoja 1 para replicar a varios PES, con el tráfico que entra a altas velocidades, y (II) la utilización del vínculo entre hojas-1 y LS-1, ya que este vínculo tiene que transportar los paquetes destinados a todos los PE en el subyacente.

’¿Sería estupendo si LS-1, que suele ser un dispositivo de gama alta, podría ‘ser útil’ en responsabilidad de la duplicación a otros PES? Así. Si LS-1 puede servir de hoja-1 con la carga de la duplicación a otros PEs, se solucionarán los problemas mencionados. ¿Cómo?

Supongamos que’Leaf-1 envía solo una copia del paquete a LS-1 y LS-1 asume el papel de la replicación y se replica a otros dispositivos EVPN del tejido. La hoja 1 sólo necesita enviar un paquete al LS-1, por lo que la carga de replicación en la hoja 1 y el número de paquetes que fluyen por el vínculo entre hojas-1 y LS-1 se reducen en un factor de 200.

Por supuesto, LS-1 debe tener la capacidad y la configuración ‘para’ ayudar a este tipo de replicación. Asimismo, LS-1 debe intercambiar esta capacidad con otros dispositivos de EVPN y los otros dispositivos para descargar la responsabilidad de duplicación a LS-1. Los túneles en los que se debe reenviar el tráfico también serán coordinados.

Figure 3: Flujo de tráfico de replicación asistido en el subyacente
Flujo de tráfico de replicación asistido en el subyacente

Permite especificar la replicación asistida. En este capítulo, se describe la replicación asistida (ar), sus características y las ventajas que aporta a la tabla para reducir la carga y la complejidad. En capítulos posteriores, una vez que se ha introducido una multidifusión optimizada, también se explora lo que es AR, junto con la multidifusión optimizada, de manera eficaz que la estructura de CC funcione de forma sencilla para el tráfico de multidifusión.

An Important Thing to Note

La funcionalidad AR es opcional. Es decir, no es obligatorio implementar AR para poder optimizar el tráfico de transmisión múltiple (una descripción que se llega en capítulos posteriores). Algunos clientes garantizan que el tráfico de multidifusión se optimice primero en el tejido y, luego, continúe con el tratamiento de los problemas de uso del ancho de banda de carga y de conexión. Sin embargo, por razones académicas, AR se adapta en este capítulo a la comprensión escalonada de los distintos mecanismos de multidifusión EVPN.

Bloques de construcción de replicación asistida

Existen tres componentes de la solución AR en la estructura, tal y como Figure 4se muestra en:

  • la función de la hoja AR

  • la función de AR-Replicator

  • la función de RNVE (equipo de virtualización de red regular): un dispositivo que no admite la característica AR

Figure 4: Roles de replicación asistidos
Roles de replicación asistidos

El AR-hoja en nuestra topología será las hojas y el rol de AR Replicator será LS-1 y LS-2. LS-1 y LS-2, antes de AR, participan en la subyacente del tejido. Con AR, estos dispositivos también realizarán las funciones adicionales de AR Replicator en la capa superpuesta. De este modo, no hay una introducción adicional del hardware y el dispositivo existente se utiliza para resolver los dos problemas de la replicación de entrada que se describieron anteriormente.

Leaf-1, hoja-2, hoja-3 y hoja 4 se configuran como AR-LEAF. (AR-L)

BL-1 y BL-2 están configurados también como AR hojas.

AR-R1 y AR-R2 están configurados como AR Replicators.

(AR-R) No hay ninguna configuración AR en la hoja-5. Esto hace que LEAF-5, el RNVE.

Requisitos de la replicación asistida en el tejido

El EVPN PEs debe designarse con un rol AR específico que utilice una configuración (AR-LEAF/Replicator) o una ausencia de él. (RNVE)

Los dispositivos EVPN deben ser capaces de detectar la presencia de otros dispositivos AR y sus roles.

Los dispositivos compatibles con AR (por lo tanto, AR-LEAFs y AR-Replicators) deben acomodar dispositivos RNVE (por lo tanto, dispositivos incapacitados para AR).

El PEs de AR-LEAF debe ser capaz de crear túneles de AR a AR Replicators para enviar tráfico de multidifusión a AR Replicators.

El PEs de AR-Replicator debe ser capaz de usar túneles de INFRARROJOs existentes para enviar tráfico de multidifusión replicado a otros dispositivos y RNVEs de niveles AR.

Los replicadores de AR y AR-LEAF deben poder utilizar los túneles de INFRARROJOs existentes para recibir tráfico de RNVEs.

Asegúrese de que el comportamiento de multitarjeta EVPN y el reenvío están en paridad con IR.

Debe haber disposiciones para admitir varios roles AR-Replicator para equilibrar la carga de la replicación. Los dispositivos de la HOJAa AR deben ser capaces de equilibrar la carga entre varios dispositivos AR-Replicator. En las implementaciones típicas de clientes, habría dos o cuatro replicadores AR en el fabric para balancear la carga y resiliencia.

Creación de túnel para replicación asistida en el tejido

AR-R1 y AR-R2, en virtud de los replicadores, anuncian una ruta a AR tipo 3, además del tipo 3 de la actualidad de INFRARROJOs. Los parámetros de ruta AR tipo 3 se utilizan en la creación de los túneles AR desde la HOJAa AR hasta el AR-Replicator.

Las hojas 1-4, AR hojas, al recibir la ruta AR-Type-3 de AR-R1 y AR-R2, deducir la presencia de replicadores y crear el túnel AR a los replicadores.

La hoja AR detecta varios replicadores, gracias a la forma en que crean la capacidad de equilibrio de carga en sus túneles de AR. Por lo tanto, algunos flujos se enviarán a ar-R1 para replicación, y otros a AR-R2.

Los replicadores AR y AR, y los superRNVE crean los túneles de INFRARROJOs entre sí según las rutas de tipo 3 existentes.

Los replicadores de INFRARROJOs y AR-a-hoja son, entre otras dos razones: (1) para que una hoja reciba tráfico replicado desde AR-R, y, (2) para retroceder a IR a cuando falle el túnel AR por cualquier motivo.

Reglas de reenvío de tráfico de replicación asistida

Assisted Replication Traffic Forwarding with Traffic Arriving From Behind AR-LEAF

Cuando llega el tráfico de multidifusión de la interfaz de acceso en hoja-1, LEAF-1 envía el tráfico a uno de los replicadores, como AR-R1. HOJA-1 envía sólo una copia de este tráfico a AR-R1 en el túnel AR.

AR-R1, tras recibir el tráfico en el túnel AR, replica este paquete a las otras hojas de AR, otras ARs y RNVEs (hoja-2, hoja-3, hoja-4, BL-1, BL-2), (AR-2) y (LEAF-5). El tráfico replicado se envía a los niveles AR y RNVEs en el túnel de INFRARROJOs.

El PEs receptor obtiene este tráfico replicado en su túnel de INFRARROJOs existente. Por lo tanto, el comportamiento es el mismo que con los túneles de INFRARROJOs existentes. Por lo tanto, reciben el tráfico de multidifusión en el túnel de INFRARROJOs y lo reenvían a las interfaces de acceso.

Assisted Replication Traffic Forwarding with Traffic Arriving From Behind RNVE

Cuando el tráfico de multidifusión llega a la interfaz de acceso de RNVE (hoja-5), la propia RNVE de la propia replicación y envía una copia cada uno del tráfico a todas las demás hojas, ARs y BLs (de entrada clásica) del túnel de INFRARROJOs.Recuerde que no hay ninguna configuración ar ni túnel ar en RNVE.

Al recibir este tráfico de RNVE, los replicadores AR no deben replicarse más para garantizar que no se produzcan duplicados. ¿Cómo puede el replicador AR a los clientes distinguir qué tráfico replicarse (desde detrás de la hoja) y cuál es el tráfico que no debe replicarse (desde la parte trasera de RNVE)? AR-1 averigua esto al comprobar el tipo de túnel en el que llegó el tráfico. Por lo tanto, si el tráfico llegase al túnel AR, se replica a otros PEs, y si llega al túnel IR, no se replica.

Resumen de reglas de reenvío de túnel cardinal AR/IR

AR-Replicator

  • En AR-R, si el tráfico llegó en túnel AR, replicarse:

    • enviar tráfico replicado a hoja, RNVE y AR en túnel de INFRARROJOs

  • En AR-R, si el tráfico llega al túnel IR, no se replica.

AR-LEAF

  • En hoja-1, para el tráfico de acceso, enviar una copia a AR-R en AR-Tunnel

  • En la hoja 1, el tráfico que llega a la dirección de INFRARROJOs, avanza sobre el acceso (comportamiento existente).

  • RNVE: Se aplican las reglas de envío y recepción de INFRARROJOs existentes

Replicación asistida en un entorno de host múltiple

EVPN Multihoming Local Bias Refresher

Vuelva a visitar EVPN de multidifusión EVPN Intra-VLAN Multicast Without Optimization la’cobertura de la optimización del capítulo 1 del EVPN de reenvío de multidifusión en topologías de host múltiple. Esta’es una versión rápida: ’Supongamos que en Figure 5, hoja 1 y hoja 2 son multitarjeta en ESI-1 y que el tráfico de multidifusión llega a la ESI-1 en la hoja 1. Cuando la entrada LEAF-1 replica el paquete en la hoja del interlocutor de host múltiple-2, LEAF-2 no debe reenviar la ESI-1, ya que podrían producirse bucles/duplicados. ¿Cómo evita el reenvío de la hoja 2 a ESI-1?

HOJA 2 examina la dirección IP de origen del paquete e averigua que se ha originado en la hoja 1. En función de esto, hoja-2 no avanza en el ESIs de host múltiple con hoja 1. En este caso, ESI-1. La hoja 2 avanzaría en otras interfaces de base único y en otros ESIs donde no es de host múltiple con hoja 1.

Assisted Replication In a Multihomed Environment – AR-R Should Retain the Src-IP of the Replicated Packet

Dado el anterior, cuando presentamos AR en la estructura, es necesario tener cuidado con el paquete que el AR replica y envía. Es decir, es fundamental que la dirección IP de origen del paquete replicado se mantenga como hoja 1 para que la diferencia local funcione correctamente.

Figure 5: Replicación asistida en entornos de hosts múltiples
Replicación asistida en entornos de hosts múltiples

Si AR-R establece su propio IP (AR-R-IP) como la dirección IP src del paquete replicado, LEAF-2 terminaría el envío en ESI-1 (dado que hoja-2 considera que es un paquete de AR-R (núcleo) y no de hoja-1).

Si esto ocurre, la hoja 2 se encuentra en un lugar, ya que realmente no puede saber si este paquete duplicado se originó en la hoja 1 (multitarjeta) o en la hoja 3 (no multitarjeta). LEAF-2 lo tratará como un paquete BUM regular que provenga del núcleo y lo reenviará a la ESI (dado que es DF en la ESI) causando duplicados/loops en la MH-ESI.

Es posible que no siempre sea posible que AR-Replicator conserve la dirección IP src del paquete de entrada en el paquete replicado (en algunas plataformas).

La funcionalidad de replicación asistida en AR-R consiste en recibir un paquete en un VTEP (túnel de AR) y, a continuación, replicarlo en otros VTEPs de (túnel de INFRARROJOs). Cuando el dispositivo AR replica y envía el paquete en VTEP siguientes procedimientos de reenvío clásico, en algunas plataformas, el dispositivo AR solo puede colocar su propia IP (AR-R-IP) como src-IP.

Normalmente, cuando un PE de entrada Replica tráfico que llega a tener acceso, crea varias copias y envía al PEs remoto, con el origen src-IP del encabezado de VXLAN exterior como su propia IP. Antes de lo dispuesto en este caso, nunca había necesidad de transformar un paquete que llegase al núcleo y devolverlo al núcleo con el origen src-IP mantenido.

En general, la replicación de entrada siempre era tomar un paquete entrante de la interfaz de acceso y replicarlo hacia el núcleo de su propio src-IP en el encabezado exterior. Puede ser difícil agregar la funcionalidad de Addi para poder tomar un paquete entrante desde la interfaz central y replicarlo hacia la propia interfaz principal mientras se marca el origen src-IP como el paquete’entrante s src-IP.

Note

Dado que interviene un tratamiento especial y que éste es un comportamiento de reenvío único, algunas plataformas no cuentan con la capacidad de conservar src-IP de LEAF-1.

Procedimiento mejorado de replicación asistida para el rescate

AR ofrece una enorme ventaja, ya que la limitación de algunas plataformas descritas en la sección anterior como no capaz de conservar src-IP no debe obstaculizar la adopción de AR. Si hubiera podido cooperar con los dispositivos LEAF/Replicator y encargarse de esta situación, merecería la pena. Afortunadamente, esto puede resolverse, y se hace referencia a él como una replicación Asistida mejorada.

Capability Exchange

En su tipo-3 AR enrutamiento, AR-Replicator anuncia su capacidad de conservar src-IP por medio de un valor extendido de la comunidad. Un valor del modo base-ar en la ‘comunidad significaría que puedo conservar la dirección IP src-ID de Leaf-’ 1 y un valor ‘Enhanced-ar’ en la comunidad, ‘no tengo la capacidad de conservar src-IP of Leaf-1.’

AR-R Capable of Retaining the Source-IP of LEAF-1

Si AR-R es capaz de conservar src-IP, entonces todo estará bien. AR-R envía de forma adecuada el valor comunitario, lo que sugiere que está en el modo base AR. Basándose en el intercambio, los dispositivos AR-hoja y AR-Replicatordevices siguen los procedimientos descritos anteriormente en los procedimientos simples de AR. También somos buenos en escenarios de host múltiple.

Dado que la dirección IP de origen de hoja-1 se conserva en el paquete replicado, hoja 2, al recibir el paquete desde el ARR, averigua la dirección IP src del paquete que debe ser de hoja-1. Con esto, se realiza una diferenciación local y se salta el reenvío en la ESI.

AR-R Not Capable of Retaining the Source-IP of LEAF-1

Si AR-R no es capaz de conservar src-IP, el AR-R establece el valor comunitario, lo que sugiere que se encuentra en modo Enhanced-AR. Los dispositivos de la hoja AR que se están familiarizando con esta comunidad entran en el modo avanzado. En este caso del modo Enhanced-AR, se requieren procedimientos adicionales tanto del AR-R como del AR-L, Figure 6tal como se muestra en la.

Figure 6: Modo AR mejorado
Modo AR mejorado

En Figure 6, ar-R deduce qué PE de ar-hoja es de host múltiple en una VLAN. Esta información está disponible y puede deducirse de la vía de tipo 1 por EVI que se anuncia para la ESIs. El alias de MAC utiliza esta información ya.

Una vez que AR-R deduce que la hoja 1 y la hoja 2 son de host múltiple, cuando recibe tráfico de la hoja 1 y se replica a otras hojas, AR-R omite el envío del paquete replicado solo a Leaf-2, por lo tanto, los interlocutores multitarjeta a los que se encuentra de hoja 1 son de host múltiple.

Dado que AR-R ha omitido el envío a hoja-2, debería haber otros medios para enviar dicho tráfico a hoja-2. Por lo tanto, LEAF-1, la hoja AR, envía una copia del tráfico de acceso al duplicador y otra copia a LEAF-2 solo a través de túnel de INFRARROJOs. (a sus compañeros de MH en esa VLAN). Es necesario enviarlo a hoja-2, ya que hoja-2 puede tener otras interfaces de host único en las que es necesario enviar este tráfico.

Cuando hoja-2 recibe tráfico de hoja-1, examinará la dirección IP src del paquete y hará lo que’sea necesario (DST-local-bias). Dado que LEAF-2 ya se ha recibido directamente de LEAF-1, puede llevar a cabo la diferencia local y no enviarla a través del vínculo ESI, pero puede avanzar en las interfaces de alojamiento único.

De esta manera, hemos llegado a la mitad del tiempo de derivar las ventajas de AR, ya que también se trata en escenarios con varias bases de alojamiento de bases de conocimientos.

Procedimientos generales de replicación asistida

AR-Replicator:

  • En AR-R, si el tráfico llegó en túnel AR, se replicará

    • Enviar tráfico replicado a hoja, RNVE y AR en túnel de INFRARROJOs

  • En AR-R, si el tráfico llegó al túnel IR, no replique

AR-LEAF:

  • En hoja-1, para el tráfico de acceso, envíe una copia a AR-1 en el túnel AR

    • De hoja 1, tráfico que llega hacia el IR, hacia delante sobre el acceso (comportamiento existente)

  • RNVE: Se aplican las reglas de envío y recepción de INFRARROJOs existentes

Enhanced-AR Additional Forwarding Rules, in Addition to Base-AR mode:

  • AR-R omite el envío del paquete replicado a hoja-2.

    • HOJA-1 hace una copia adicional en la hoja 2 solamente, y envía a través de un túnel IR.

Resumen del capítulo

Este capítulo ha explorado la replicación asistida, sus ventajas, los procedimientos básicos, las limitaciones de la plataforma con escenarios de EVPN MH y los procedimientos para detectarlos y acomodarlos.

Con AR, transferimos la carga de la replicación desde los dispositivos de hoja de low-end a los dispositivos capaces de HIGHEND Replicator, lo que reduce de manera eficaz la carga de la replicación en la hoja y evita el uso excesivo del ancho de banda del vínculo entre las hojas y el lomo eficiente. El lomo subyacente eficiente de la existente realiza el papel adicional de Replicator.

En entornos de multihost AR cuenta con dos modos, básicos y mejorados. Tenemos la capacidad de intercambiar con una comunidad ampliada en la ruta de CC de tipo 3.

En el modo base-AR, donde se conserva la IP de src de la hoja, los procedimientos de diferencia local clásica, los de host múltiple funcionan automáticamente para garantizar que los duplicados no se produzcan, ya que AR-R de la hoja de origen se mantiene a través del superpuesto.

En el modo Enhanced-AR donde no se conserva la dirección IP de src de la hoja, se siguen los procedimientos avanzados AR para garantizar que no se produzcan duplicados. Esto lo consigue el AR-R, que envía el paquete replicado al sistema de mismo nivel de host múltiple y el PE de entrada envía una copia a AR-R y otra copia a la propia de multitarjeta del mismo nivel.

A la vez que se observan’capítulos, analizamos los primeros pasos hacia la optimización de la multidifusión. Comenzaremos por la OB para optimizar el modo en que se optimiza el tráfico hacia el punto de acceso, seguido del modo en que el tráfico hacia el centro se mejora.

En EVPN Base Configuration in DC Fabric Topology y EVPN Intra-VLAN Multicast Without Optimization capítulo, se ha explorado la inundación del tráfico de multidifusión en todo el mundo. Por lo tanto, el tráfico se envía a todos los PE de salida e interfaces de acceso, y el PEs de salida envía a su vez sus interfaces de acceso.

Como se mencionó anteriormente, la comprensión de los conceptos de AR o sus procedimientos no es un requisito previo para continuar con la obtención de distintas optimizaciones de multidifusión en los siguientes capítulos. A medida que se presenta cada faceta de optimización, describimos cómo podría encajarse en si AR también se implementa junto con la optimización.