Funciones mejoradas de BGP (equipo Huawei)

Atenuación de ruta:

Inserte la descripción de la imagen aquí
La amortiguación de rutas se utiliza para resolver el problema del enrutamiento inestable. En la mayoría de los casos, el protocolo BGP se utiliza en entornos de red complejos y los cambios de enrutamiento son frecuentes. Para evitar los efectos adversos de las oscilaciones continuas de la ruta, BGP utiliza la atenuación de la ruta para suprimir las rutas inestables.

La atenuación BGP utiliza el valor de penalización para medir la estabilidad de una ruta. Cuanto mayor sea el valor de penalización, más inestable será la ruta. Cada vez que una ruta flap (la ruta cambia de un estado activo a un estado inactivo, se llama flap de ruta), BGP agregará un cierto valor de penalización (1000) a esta ruta. Cuando el valor de penalización excede el umbral de supresión (Suppress Value), la ruta se suprime, no se agrega a la tabla de enrutamiento y ya no anuncia paquetes de actualización a otros pares BGP.

El valor de penalización de la ruta suprimida se reducirá a la mitad después de un período de tiempo, este tiempo se denomina vida media. Cuando el valor de la penalización cae al umbral de reutilización (Valor de reutilización), la ruta se vuelve disponible y se agrega a la tabla de enrutamiento. Al mismo tiempo, anuncia paquetes de actualización a otros pares BGP. El valor de penalización, el umbral de supresión y la vida media mencionados anteriormente se pueden configurar manualmente.

La atenuación de ruta solo se aplica a rutas EBGP. Las rutas recibidas de IBGP no se pueden atenuar, porque las rutas IBGP a menudo contienen rutas en este AS. Las rutas de la red interna requieren que la tabla de reenvío sea lo más consistente posible. La convergencia rápida de IGP es lograr sincronización de información y consistencia de reenvío. Si la atenuación afecta el enrutamiento IBGP, los parámetros de atenuación de diferentes dispositivos son inconsistentes, lo que resulta en tablas de reenvío inconsistentes.
1. Ejecute el comando bgp as-number para ingresar a la vista BGP.

2. Ejecute el comando ipv4-family unicast para ingresar a la vista de familia de direcciones unicast IPv4.

3. Configure los parámetros de atenuación de la ruta BGP.

Configure los parámetros de atenuación de la ruta EBGP.
• Ejecute el comando ipv4-family unicast para ingresar a la vista de familia de direcciones unicast IPv4.
• Ejecute el comando amortiguación [half-life-reach reutilización suprimir techo | route-policy route-policy-name] * [update-standard] para configurar los parámetros de atenuación de la ruta EBGP.

Configure los parámetros de atenuación de la ruta IBGP.
• Ejecute el comando ipv4-family vpnv4 para ingresar a la vista de familia de direcciones BGP-VPNv4.
• Ejecute el comando amortiguación ibgp [half-life-reach reutilización suprimir techo | route-policy route-policy-name] * [update-standard] para configurar los parámetros de atenuación de ruta IBGP.

Al configurar la atenuación de ruta BGP, los tres umbrales especificados de reutilización, supresión y techo aumentan en secuencia, es decir, deben cumplir: reutilización <suprimir <techo.
Al distinguir rutas por política, cuando el comando de amortiguación hace referencia a políticas de enrutamiento, BGP puede usar diferentes parámetros de amortiguación para suprimir diferentes rutas.

Por ejemplo: [R1-bgp] amortiguación 1 1000 2000 3000 // Significa que la vida media es 1 minuto, el umbral es 1000 y la supresión de entrada comienza cuando excede 2000. El valor de penalización puede alcanzar 3000 y no continuará La penalización predeterminada El valor aumenta en 1000 por turbulencia. Cuando se suprime la entrada debido a una descarga, la marca de entrada cambiará a H:
Inserte la descripción de la imagen aquí

Características de BGP ORF:

Inserte la descripción de la imagen aquí
La capacidad ORF basada en prefijo de BGP puede enviar la política de ingreso basada en prefijo configurada por el dispositivo local a los vecinos BGP a través de mensajes de actualización de ruta. Los vecinos de BGP construyen políticas de exportación basadas en estas políticas y filtran las entradas de enrutamiento al enviar rutas (filtrar al enviar es la mejor manera de reducir el desperdicio de ancho de banda). Esto no solo evita que el dispositivo local reciba una gran cantidad de rutas inútiles, reduce el uso de CPU del dispositivo local, sino que también reduce efectivamente la configuración de vecinos BGP y reduce el uso de ancho de banda del enlace. (Solo puede coincidir con la lista de prefijos)

Descripción topológica:

  1. En vecinos EBGP conectados directamente, después de que Client1 y R1 negocian la capacidad ORF basada en prefijos, Client1 empaqueta la política de entrada basada en prefijo configurada localmente en un mensaje de actualización de ruta y la envía a R1. R1 construye una política de salida de acuerdo con el mensaje de actualización de ruta recibido y envía una ruta al Cliente1 a través de un mensaje de actualización de ruta. Client1 solo recibe las rutas que necesita y el R1 no necesita mantener políticas de enrutamiento, lo que reduce el trabajo de configuración.
  2. Client1 y Client2 son clientes RR. Client1 y RR, Client2 y RR respectivamente negocian la capacidad ORF basada en prefijo. Client1 y Client2 empaquetan la política de entrada basada en prefijo configurada localmente en un mensaje de actualización de ruta y lo envían a RR. El RR construye una política de salida de acuerdo con la información de prefijo recibida y refleja la ruta a Client1 y Client2 a través de paquetes de actualización de ruta. Client1 y Client2 solo reciben las rutas requeridas, y el RR no necesita mantener políticas de enrutamiento, lo que reduce el trabajo de configuración.

Configuración:

  1. Ejecute el comando bgp as-number para ingresar a la vista BGP.
  2. Ejecute el comando unicast ipv4-family para ingresar a la vista de familia de direcciones unicast IPv4.
  3. Ejecute el comando de importación peer {group-name | ipv4-address} ip-prefix ip-prefix-name import para configurar la política de filtrado de ruta de entrada del grupo de pares / pares según la lista de prefijos de IP.
  4. Ejecute el comando peer {nombre-grupo | dirección-ipv4} capacidad-publicidad orf [compatible no estándar] prefijo-ip {ambos | recibir | enviar} para configurar pares BGP (grupos) para habilitar ORF basado en prefijos de dirección.

Experimento:
Inserte la descripción de la imagen aquí
Propósito: Configurar en R2, dejar que el valor R1 envíe las entradas 1.1.1.0/24 y 2.2.2.0/24.

Configurar en R1:
bgp 1
peer 10.1.1.2 como número 2

ipv4-family unicast
deshacer sincronización
red 1.1.1.0 255.255.255.0
red 2.2.2.0 255.255.255.0
red 3.3.3.0 255.255.255.0
red 4.4.4.0 255.255.255.0
peer 10.1.1.2 habilitar
peer 10.1.1.2 capacidad-anunciar orf ip-prefix recibir // 作为 接收 端

Configurar en R2:
ip ip-prefix huawei index 10 deny 3.3.3.0 24 // Rechazar la entrada correspondiente
ip ip-prefix huawei index 20 deny 4.4.4.0 24
ip ip-prefix huawei index 30 permit 0.0.0.0 0 less-equal 32 // Permitir todas las demás entradas

bgp 2
par 10.1.1.1 como número 1

ipv4-family unicast
deshacer sincronización
peer 10.1.1.1 enable
peer 10.1.1.1 ip-prefix huawei import // Primero, debe llamar a la lista de prefijos
peer 10.1.1.1 Capacity-Advertise orf ip-prefix send // como remitente de actualización mensajes en la dirección entrante final

Resultado de la detección:
Inserte la descripción de la imagen aquí
Inserte la descripción de la imagen aquí
se puede ver en la captura de paquetes que solo 1.1.1.0/24 y 2.2.2.0/24 son enviados por R1, y solo hay entradas de enrutamiento correspondientes en la ruta BGP de R2:
Inserte la descripción de la imagen aquí
Nota: Se volverá a configurado después de que se configura ORF Establecer vecinos sin actualizar.

Sincronización BGP:

Inserte la descripción de la imagen aquí
Propósito:
Asegurar que el tráfico de entradas BGP aún pueda pasar en el entorno IGP y evitar el enrutamiento de agujeros negros.

Descripción de la topología (cuando la sincronización está habilitada):
R4 aprende la red 10.0.0.0/24 anunciada por R1 a través de BGP (cuando aprende la ruta correspondiente de los pares IBGP). Antes de que R4 anuncie la red a R5, primero verificará si la red 10.0.0.0/24 ya existe en su tabla de enrutamiento IGP. Si la entrada de la tabla de enrutamiento IGP local de R4 tiene una red 10.0.0.0/24, la red se anunciará a R5; si la entrada de la tabla de enrutamiento IGP local de R4 no tiene una red 10.0.0.0/24, la red no se puede anunciado a R5. Si desea tener entradas de enrutamiento 10.0.0.0/24 en la tabla IGP de R4, debe redistribuir BGP en el IGP para que, obviamente, no sea deseable permitir una gran cantidad de entradas en el IGP.

Por supuesto, en la plataforma Huawei VRP, la sincronización BGP está deshabilitada de forma predeterminada y no se puede habilitar manualmente. Luego, hay dos formas comunes de resolver el problema del agujero negro del enrutamiento BGP:

  1. Establezca conexiones iBGP completamente interconectadas para que cada enrutador pueda recibir rutas para garantizar la accesibilidad dentro del AS.
  2. Utilice la tecnología VPN MPLS para resolver, los detalles específicos se discutirán en las notas MPLS.

Anuncio de ruta activa 特性 :

Inserte la descripción de la imagen aquí

  1. De forma predeterminada, las rutas solo necesitan optimizarse en BGP para anunciarse a los vecinos. Una vez configurada esta función, las rutas deben cumplir las dos condiciones de estar optimizadas en el nivel de protocolo BGP y estar activas en el nivel de administración de rutas antes de que puedan anunciarse a los vecinos.
  2. Es mutuamente excluyente con el comando bgp-rib-only (usado para prohibir que las rutas BGP se envíen a la tabla de enrutamiento IP), porque cuando se configuran juntas, no se permite agregar todas las entradas a la tabla, y definitivamente no lo harán. ser enviado al extremo opuesto.

Configuración:
[R1-bgp] active-route-advertisement // Ingrese la configuración del proceso

BGP está empaquetado en grupos:

Inserte la descripción de la imagen aquí

  1. De forma predeterminada, BGP empaqueta rutas separadas para diferentes vecinos (incluso si la política de exportación es la misma).
  2. Después de aplicar la función de empaquetado grupal, cada ruta a enviar solo se empaqueta una vez y luego se envía a todos los vecinos del grupo, lo que duplica la eficiencia del empaque. (La premisa es que la información enviada a los vecinos es la misma, por lo que no necesita generar un paquete en la dirección de salida para cada vecino, solo genere uno uniformemente).

Descripción de la topología:
un reflector tiene 3 clientes y es necesario reflejar 100.000 rutas. Si cada vecino se empaqueta por separado, cuando el reflector RR envía rutas a tres clientes, el número total de veces que se empaquetan todas las rutas es 100.000 × 3. El empaquetado por tecnología de grupo convierte este proceso en 100.000 × 1, lo que equivale a triplicar el rendimiento.

Escenario común:
Inserte la descripción de la imagen aquí
diagrama de red típico de reflectores para varios clientes:
Inserte la descripción de la imagen aquí

Diagrama de red típico de PE que conecta múltiples vecinos IBGP:
Inserte la descripción de la imagen aquí
Experimento:
Inserte la descripción de la imagen aquí
R1 establece una relación de vecino IBGP con R2, R3, la configuración normal en R2, R3 y R1 se configura de manera empaquetada:

bgp 1
group huawei internal // Crear un grupo interno, aplicable a IBGP vecino
peer huawei connect-interface LoopBack0 // Establecer una relación con el vecino del grupo huawei a través de la interfaz L0
peer 10.1.1.2 as-number 1 // Este comando se genera automáticamente, IBGP El vecino no debe configurar este comando porque es el mismo que su propio número AS. Si es un vecino EBGP, debe configurar el número AS del otro
peer 10.1.1.2 grupo huawei // Configurar el vecino 10.1 .1.2 como el
peer vecino creado por el empaquetado en el grupo huawei 10.1.1.3 como
peer número 1 10.1.1.3 group huawei // Configure el vecino 10.1.1.3 como un vecino empaquetado en el grupo huawei

ipv4-family unicast
deshacer sincronización
peer huawei enable
peer huawei next-hop-local // Al enviar a todos los miembros del grupo huawei, el siguiente salto es su
par 10.1.1.2 enable
peer 10.1.1.2 group huawei
peer 10.1.1.3 enable
peer 10.1.1.3 grupo huawei

Inserte la descripción de la imagen aquí

AS de 4 bytes:

Inserte la descripción de la imagen aquí
Descripción topológica

  1. R2 recibe una ruta AS de cuatro bytes de R1, el número AS es 10.1.
  2. R2 y R3 establecen un vecino, y R3 necesita pensar que el número AS de R2 es AS_TRANS.
  3. Cuando R2 envía una ruta a R3, registra AS_TRANS en AS_Path y registra 10.1 y su propio AS número 20.1 en AS4_Path en el orden requerido por BGP.
  4. R3 no procesa el atributo no reconocido AS4_Path y aún lo retiene, solo envía rutas a RD de acuerdo con las reglas BGP. Por supuesto, piensa que el número AS de R4 también es AS_TRANS.
  5. De esta manera, cuando R4 recibe una ruta de R3, reemplazará AS_TRANS en AS_PATH con la dirección correspondiente registrada en AS4_Path en orden, y restaurará el atributo AS_PATH a 30 20.1 10.1 en R4.

Rol definido por número AS de 4 bytes:

  1. Nuevo altavoz: un par que admite capacidades de extensión de número AS de 4 bytes.
  2. Orador antiguo: un par que no admite capacidades de extensión de número AS de 4 bytes.
  3. Nueva sesión: conexión BGP establecida entre nuevos oradores.
  4. Sesión anterior: conexión BGP establecida entre el nuevo orador y el antiguo o entre el antiguo.

Extensión de protocolo:

  1. Se definen dos nuevos atributos de transición opcionales AS4_Path (código de atributo 0x11) y atributos AS4_Aggregator (código de atributo 0x12) para transmitir información AS de 4 bytes en la sesión anterior.
  2. Si el nuevo altavoz y el antiguo altavoz establecen una conexión, defina AS_TRANS (valor reservado 23456) para conectar el AS de 2 bytes y el AS de 4 bytes. Y no se puede volver a cambiar después de 23456.

Hay tres formas de escribir el nuevo número AS: (Huawei admite la escritura asdot)

  1. splain: Es un número decimal.
  2. asdot +: escrito en forma de (2 bytes). (2 bytes), por lo que el antiguo ASN123 de 2 bytes se puede escribir como 0,123, y ASN65536 es 1,0; el máximo es 65535,65535.
  3. asdot: los 2 bytes antiguos se escriben como de costumbre y los 4 bytes nuevos se escriben en asdot +. (1-65535; 1.0-65535.65535)

Siga la estrategia para la iteración del próximo salto:

Inserte la descripción de la imagen aquí
BGP necesita iterar en el siguiente salto que no está conectado directamente, pero si la ruta iterada no se filtra, puede iterar a una ruta de reenvío incorrecta. La iteración del siguiente salto de acuerdo con la estrategia es restringir la ruta iterada configurando la estrategia de enrutamiento. Si la ruta no puede pasar la política de enrutamiento, la iteración de la ruta falla.

Descripción topológica:

  1. Los vecinos IBGP se establecen entre R1 y R2 y R3 a través de la interfaz Loopback. R1 recibe rutas BGP con el prefijo 10.0.0.0/24 de R2 y R3 respectivamente. El siguiente salto original de la ruta BGP recibida de R2 es 2.2.2.2. Además, la dirección de interfaz de Ethernet0 / 0/0 en R1 es 2.2.2.100/24.
  2. Cuando R2 se ejecuta normalmente, R1 recibe la ruta con el prefijo 10.0.0.0/24 de R2 e itera a la ruta IGP 2.2.2.2/32. Pero cuando falla el IGP de R2, se revoca la ruta IGP 2.2.2.2/32, lo que hace que se repita el siguiente salto. En R1, el siguiente salto original 2.2.2.2 se utilizará para realizar la iteración de coincidencia más larga en la tabla de enrutamiento IP, y el resultado se repetirá en la ruta 2.2.2.0/24. Pero lo que el usuario espera en este momento es que cuando la ruta a 2.2.2.2 sea inalcanzable, la ruta a 3.3.3.3 se pueda volver a seleccionar y preferir. De hecho, la falla es causada principalmente por la convergencia BGP, que crea un agujero negro instantáneo en el enrutamiento.
  3. Configure la política iterativa del siguiente salto para filtrar la ruta iterada según la longitud de la máscara de la ruta de la que depende el siguiente salto original de la ruta BGP. Puede configurar la estrategia de iteración del siguiente salto para que el siguiente salto original 2.2.2.2 solo pueda depender de la ruta IGP de 2.2.2.2/32.

Material de referencia: documento hedex de Huawei

Supongo que te gusta

Origin blog.csdn.net/tushanpeipei/article/details/112831791
Recomendado
Clasificación