Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción general de BGP

Descripción de BGP

BGP es un protocolo de puerta de enlace (EGP) exterior que se utiliza para intercambiar información de encaminamiento entre enrutadores de diferentes sistemas autónomos (Asoc). BGP información de enrutamiento incluye la ruta completa a cada destino. BGP utiliza la información de enrutamiento para mantener una base de datos con información sobre el alcance de la red, que intercambia con otros sistemas BGP. BGP usa la información de disponibilidad de la red para construir un gráfico de como conectividad, lo que permite a BGP eliminar los bucles de enrutamiento y aplicar las decisiones de la Directiva en el nivel AS.

Las extensiones de BGP multiprotocolo (MBGP) permiten que BGP admitan la versión 6 de IP (IPv6).MBGP define los atributos MP_REACH_NLRI y MP_UNREACH_NLRI, que se utilizan para portar información de accesibilidad de IPv6. Los mensajes de actualización de la información de accesibilidad de la capa de red (NLRI) llevan prefijos de direcciones IPv6 de rutas factibles.

BGP permite el enrutamiento basado en políticas. Puede utilizar las directivas de enrutamiento para elegir entre varios paths hasta un destino y controlar la redistribución de la información de enrutamiento.

BGP utiliza TCP como su Protocolo de transporte, utilizando el puerto 179 para establecer conexiones. La ejecución a través de un protocolo de transporte confiable elimina la necesidad de BGP para implementar la fragmentación, la retransmisión, la confirmación y la secuencia de actualizaciones.

El software del Protocolo de enrutamiento Junos OS admite BGP versión 4. Esta versión de BGP agrega compatibilidad con Enrutamiento interdominio sin clase (EISC), lo que elimina el concepto de clases de red. En lugar de asumir que bits de una dirección representa la red mirando el primer octeto, CIDR le permite especificar explícitamente el número de bits de la dirección de red, lo que supone un medio para reducir el tamaño de las tablas de enrutamiento. BGP versión 4 también admite la agregación de rutas, incluida la agregación de rutas de AS.

En esta sección se tratan los siguientes temas:

Sistemas autónomos

Un sistema autónomo es un conjunto de enrutadores que se encuentran bajo una sola administración técnica y que normalmente utilizan un protocolo de puerta de enlace interior único y un conjunto común de métricas para difundir la información de enrutamiento dentro del conjunto de enrutadores. A otros, un AS parece tener un solo plan de enrutamiento interior coherente y presenta una imagen coherente respecto a los destinos que se pueden alcanzar a través de él.

COMO rutas y atributos

La información de enrutamiento que interBGP los sistemas intercambian incluye la ruta completa hacia cada destino, así como información adicional acerca de la ruta. La ruta a cada destino se denomina ruta de accesoy la información de ruta adicional se incluye en los atributos de ruta. BGP utiliza los atributos AS y path para determinar completamente la topología de la red. Una vez BGP entienda la topología, puede detectar y eliminar los bucles de enrutamiento, y seleccionar entre grupos de rutas para aplicar las preferencias administrativas y las decisiones de la Directiva de enrutamiento.

BGP externos e internos

BGP admite dos tipos de intercambios de información de enrutamiento: intercambios entre diferentes Asoc. e intercambios en el mismo único. Cuando se utiliza entre, BGP se denomina external BGP (EBGP) y las sesiones BGP se realizan en el enrutamiento inter. Cuando se utiliza en un AS, BGP se denomina BGP interno (IBGP) y las sesiones BGP realizan enrutamiento intra-as. Figura 1 ilustra a ase, IBGP y EBGP.

Figura 1: Asoc, EBGP y IBGPAsoc, EBGP y IBGP

Un sistema BGP comparte información de alcance de la red con sistemas BGP adyacentes, que se denominan vecinos o colegas.

Los sistemas BGP se organizan en grupos. En un grupo de IBGP, todos los pares del grupo, denominados pares internos, se encuentran en el mismo as. Los interlocutores internos pueden estar en cualquier parte del AS local y no tienen que estar directamente conectados entre sí. Los grupos internos utilizan rutas de un IGP para resolver las direcciones de reenvío. También propagan rutas externas entre todos los demás enrutadores internos que se ejecutan IBGP, lo que hace que se calcule el siguiente salto tomando BGP siguiente salto recibido con la ruta y resolviendo la información desde uno de los protocolos de puerta de enlace interior.

En un grupo EBGP, los pares del grupo, denominados pares externos, se encuentran en as diferentes y normalmente comparten una subred. En un grupo externo, el siguiente salto se calcula con respecto a la interfaz compartida entre el mismo nivel externo y el enrutador local.

Varias instancias de BGP

Puede configurar varias instancias de BGP en los siguientes niveles de jerarquía:

  • [edit routing-instances routing-instance-name protocols]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

Las instancias múltiples de BGP se utilizan principalmente para la compatibilidad con VPN de capa 3.

Los pares de IGP y BGP externos (EBGP) (tanto nonmultihop como Multihop) son compatibles para las instancias de enrutamiento. El emparejamiento BGP se establece a través de una de las interfaces configuradas bajo la routing-instances jerarquía.

Nota:

Cuando un vecino BGP envía BGP mensajes al dispositivo de enrutamiento local, la interfaz de entrada en la que se reciben estos mensajes debe configurarse en la misma sesión de enrutamiento en la que existe la BGP vecinos. Esto es así para los vecinos que no tienen un solo salto o que se alejan de varios saltos.

De forma predeterminada, los enrutadores aprendidos del par BGP se agregan a la instance-name.inet.0 tabla. Puede configurar políticas de importación y exportación para controlar el flujo de entrada y salida de información en la tabla de enrutamiento de instancias.

Para la compatibilidad con VPN de capa 3, configure BGP en el enrutador de borde del proveedor (PE) para recibir rutas desde el enrutador perimetral del cliente (BRC) y para enviar las rutas de las instancias al enrutador BRC si fuera necesario. Puede usar varias instancias de BGP para mantener tablas independientes de reenvío por sitios para mantener el tráfico VPN separado en el enrutador PE.

Puede configurar políticas de importación y exportación que permitan al proveedor de servicios controlar y limitar el tráfico hacia y desde el cliente.

Puede configurar una sesión de Multihop EBGP para una instancia de enrutamiento VRF. Además, puede configurar el EBGP del mismo nivel entre los enrutadores PE y CE utilizando la dirección de bucle invertido del enrutador de CE en lugar de las direcciones de interfaz.

Introducción a las rutas de BGP

Una ruta BGP es un destino, que se describe como un prefijo de dirección IP, e información que describe la ruta de acceso al destino.

La siguiente información describe la ruta de acceso:

  • COMO ruta de acceso, que es una lista de números de los inmovilizados que pasa una ruta para llegar al enrutador local. El primer número de la ruta es el del último AS en la ruta: el AS más cercano al enrutador local. El último número de la ruta de acceso es el más alejado del enrutador local, que generalmente es el origen de la ruta de acceso.

  • Los atributos de ruta, que contienen información adicional acerca de la ruta AS que se utiliza en la Directiva de enrutamiento.

BGP interlocutores anuncien las rutas entre sí en los mensajes de actualización.

BGP almacena sus rutas en la tabla de enrutamiento deinet.0Junos os (). La tabla de enrutamiento almacena la siguiente información sobre rutas de BGP:

  • Información de enrutamiento obtenida de mensajes de actualización recibidos de homólogos

  • Información de enrutamiento local que BGP se aplica a las rutas debido a las políticas locales

  • Información que BGP anuncia a BGP iguales del mismo nivel en mensajes de actualización

Por cada prefijo de la tabla de enrutamiento, el proceso de protocolo de enrutamiento selecciona una sola ruta óptima, denominada ruta de acceso activa. A menos que configure BGP para anunciar varias rutas de acceso al mismo destino, BGP anuncia únicamente el path activo.

El enrutador BGP que primero anuncia una ruta le asigna uno de los siguientes valores para identificar su origen. Durante la selección de la ruta, es preferible el valor de origen más bajo.

  • 0: El enrutador originalmente aprendió la ruta a través de una IGP (OSPF, SI-SI o una ruta estática).

  • 1: El enrutador originalmente aprendió la ruta a través de un EGP (probablemente BGP).

  • 2: se desconoce el origen de la ruta.

Descripción general de BGP resolución de rutas

Una ruta interna de BGP (IBGP) con una dirección de salto siguiente a un vecino de BGP remoto (protocolo siguiente) debe resolver su siguiente salto mediante otra ruta. BGP agrega esta ruta al módulo de resolución RPD para la resolución del próximo salto. Si se utiliza RSVP en la red, el BGP siguiente salto se resuelve mediante la ruta RSVP de entrada. Esto da como resultado que la ruta de BGP apunta a un salto indirecto e indirecto, y el próximo salto invariable apunta a un próximo salto de reenvío. El siguiente salto de reenvío se deriva del siguiente salto de la ruta RSVP. Suele haber un conjunto grande de rutas de BGP internas que tienen el mismo protocolo al siguiente salto y, en tales casos, el conjunto de rutas BGP haría referencia al mismo salto indirecto.

Antes de Junos OS versión 17.2 R1, el módulo de resolución del proceso de protocolo de enrutamiento (RPD) resolvió rutas dentro del IBGP recibió rutas en los siguientes aspectos:

  1. Resolución parcial de rutas: el siguiente salto de protocolo se resuelve en función de las rutas auxiliares, como las rutas RSVP o IGP. Los valores de métrica se derivan de las rutas auxiliares, y el siguiente salto se denomina reenviar el siguiente salto heredado de las rutas de la aplicación auxiliar. Estos valores métricos se utilizan para seleccionar rutas en la base de información de enrutamiento (RIB), también conocida como tabla de enrutamiento.

  2. Resolución completa de ruta: se deriva el siguiente salto final y se hace referencia a él como la tabla de enrutamiento de kernel (KRT) el reenvío del siguiente salto según la política de exportación de reenvío.

A partir de Junos OS versión de 17.2 en R1, el módulo de resolución de RPD está optimizado para aumentar el rendimiento del flujo de procesamiento de entrada, lo que acelera la velocidad de aprendizaje de las COSTILLAs y las FIB. Con esta mejora, la resolución de la ruta se ve afectada de la siguiente manera:

  • Los métodos de resolución de ruta parcial y completo se activan para cada ruta de IBGP, aunque cada ruta puede heredar el mismo salto de reenvío y reenvío KRT de saltos siguientes.

  • La selección de ruta de acceso de BGP se aplaza hasta que se realice la resolución de ruta completa para la información de acceso de la capa de red (NLRI) recibida de un vecino BGP, que podría no ser la mejor ruta en el nervio después de la selección de ruta.

Las ventajas de la optimización de la resolución de RPD incluyen:

  • Menor costo de búsqueda de resolución de COSTILLAs: la salida de la ruta resuelta se guarda en una caché de resolución, de forma que los mismos valores derivados de salto siguiente y métrico se puedan heredar en otro conjunto de rutas que compartan el mismo comportamiento de ruta, en lugar de realizar la resolución parcial y completa del flujo de ruta. Esto reduce el costo de búsqueda de resolución de ruta al mantener solo el estado de resolución más frecuente en una caché con una profundidad limitada.

  • BGP optimización de la selección de rutas: el algoritmo de selección de ruta BGP se activa dos veces para cada ruta de IBGP recibida: en primer lugar, al agregar la ruta en el nervio con el siguiente salto inutilizable, y segundo, mientras se agrega la ruta con un salto siguiente resuelto en el nervio (después de la resolución de ruta). Esto da como resultado la selección de la mejor ruta dos veces. Con la optimización de la resolución, el proceso de selección de ruta solo se activa en el flujo de recepción después de obtener la información del próximo salto del módulo de resolución.

  • Caché interna para evitar búsquedas frecuentes: la caché de resolución es la que mantiene el estado de resolución más frecuente y, como resultado, la funcionalidad de búsqueda, como la búsqueda de salto siguiente y la búsqueda de ruta, se realiza desde la memoria caché local.

  • Grupo de equivalencia de ruta: cuando diferentes rutas comparten el mismo estado de reenvío o se reciben del mismo protocolo siguiente, las rutas pueden pertenecer a un grupo de equivalencia de ruta. Este enfoque evita la necesidad de llevar a cabo una resolución completa de la ruta para tales paths. Cuando una nueva ruta requiere una resolución completa de la ruta, primero se busca en la base de datos del grupo de equivalencia de rutas, que contiene la ruta de salida resuelta, como un salto indirecto y el siguiente salto de reenvío.

Introducción a los mensajes de BGP

Todos los mensajes de BGP tienen el mismo encabezado de tamaño fijo, que contiene un campo de marcador que se utiliza tanto para la sincronización como para la autenticación, un campo de longitud que indica la longitud del paquete y un campo de tipo que indica el tipo de mensaje (por ejemplo, Open, Update, Notification, keepalive, etc.).

En esta sección se tratan los siguientes temas:

Mensajes abiertos

Después de establecer una conexión TCP entre dos sistemas BGP, intercambian BGP mensajes abiertos para crear una conexión BGP entre ellos. Una vez establecida la conexión, los dos sistemas pueden intercambiar mensajes BGP y el tráfico de datos.

Los mensajes abiertos constan del encabezado BGP junto con los siguientes campos:

  • Versión: el número de versión de la BGP actual es 4.

  • Número de AS local: para configurarlo, incluya la autonomous-system instrucción en el [edit routing-options] nivel de [edit logical-systems logical-system-name routing-options] jerarquía o.

  • Tiempo de espera: valor de tiempo de conservación propuesto. La hora local de conservación se configura con la hold-time instrucción BGP.

  • BGP identificador: dirección IP del sistema de BGP. Esta dirección se determina cuando el sistema se inicia y es el mismo para todas las interfaces locales y cada par BGP. Puede configurar el identificador de BGP si incluye la router-id instrucción en el nivel [edit routing-options] de [edit logical-systems logical-system-name routing-options] jerarquía o. De forma predeterminada, BGP utiliza la dirección IP de la primera interfaz que encuentre en el enrutador.

  • Longitud del campo de parámetro y el parámetro en sí; estos campos son opcionales.

Mensajes de actualización

Los sistemas BGP envían mensajes de actualización a la información de accesibilidad de la red de Exchange. Los sistemas BGP utilizan esta información para crear un gráfico que describa las relaciones existentes entre todos los conocidos.

Los mensajes de actualización constan del encabezado BGP junto con los siguientes campos opcionales:

  • Longitud de rutas inviables: longitud del campo de rutas retiradas

  • Rutas retiradas: prefijos de direcciones IP para las rutas que se retiran del servicio porque ya no se consideran accesibles

  • Longitud total del atributo de ruta: longitud del campo de atributos de ruta; enumera los atributos de ruta para una ruta factible hacia un destino

  • Atributos de ruta: propiedades de las rutas, incluido el origen de la ruta, el discriminador de salida múltiple (MED), la preferencia del sistema de origen para la ruta e información acerca de la agregación, las comunidades, las confederaciones y la reflexión de rutas

  • Información de accesibilidad de la capa de red (NLRI): prefijos de direcciones IP de rutas factibles que se anuncian en el mensaje de actualización

Mensajes de KeepAlive

Los sistemas BGP intercambian mensajes para determinar si un vínculo o un host han fallado o ya no están disponibles. Los mensajes de KeepAlive se intercambian con la frecuencia suficiente para que el temporizador de retención no caduque. Estos mensajes solo se componen del encabezado BGP.

Mensajes de notificación

Los sistemas BGP envían mensajes de notificación cuando se detecta una condición de error. Después de enviar el mensaje, se cerrará la sesión de BGP y la conexión TCP entre los sistemas BGP. Los mensajes de notificación constan del encabezado BGP, junto con el código de error y el subcódigo, y los datos que describen el error.

Mensajes de Actualizar de enrutamiento

Los sistemas BGP envían mensajes de actualización de ruta a un sistema del mismo nivel solo si han recibido el anuncio de capacidad de actualización de ruta del interlocutor. Un sistema de BGP debe anunciar la capacidad de actualización de la ruta a sus homólogos mediante BGP anuncio de capacidades si desea recibir mensajes de actualización de ruta. Este mensaje opcional se envía para solicitar actualizaciones dinámicas, de entrada BGP de ruta desde BGP iguales o para enviar actualizaciones de rutas salientes a un par BGP.

Los mensajes de actualización de ruta constan de los siguientes campos:

  • AFI: identificador de familia de direcciones (16 bits).

  • Res: campo reservado (8 bits), que el remitente debe establecer en 0 y que el receptor lo pasó por alto.

  • SAFI: identificador de familia de direcciones subsiguiente (8 bits).

Si un interlocutor sin la capacidad de actualización de ruta recibe un mensaje de solicitud de actualización de ruta de un sistema del mismo nivel remoto, el receptor omite el mensaje.

Descripción de BGP subproceso de e/s de actualización

BGP el procesamiento de ruta generalmente tiene varias etapas de canalización, como la recepción de actualizaciones, el análisis de actualización, la creación de rutas, la resolución del próximo salto, la aplicación de una política de exportación de un grupo de par BGP, la formación de actualizaciones por par y el envío de actualizaciones a los pares. Los subprocesos de e/s de BGP Update son responsables de la finalización de esta canalización del BGP, lo que implica generar actualizaciones por interlocutor para grupos de BGP individuales y enviarlos al mismo nivel (s). Un subproceso de actualización puede servir a uno o varios grupos BGP. Los subprocesos IO de BGP Update crean actualizaciones para grupos en paralelo e independientes de otros grupos que reciben el mantenimiento de otros subprocesos de actualización. Esto podría ofrecer una mejora considerable de la convergencia en una carga de trabajo pesada, que implica publicidad para muchos elementos del mismo nivel en varios grupos. Los subprocesos de e/s de BGP Update también son responsables de escribir y leer de los Sockets TCP del BGP del mismo nivel que anteriormente proporcionaban los subprocesos BGPIO (y, por lo tanto, el sufijo IO en la actualización de e/s de BGP).

Los subprocesos IO de actualización BGP pueden configurarse con independencia de la función de particionamiento de nervio pero son obligatorios para su uso con el particionamiento de COSTILLAs, a fin de lograr una mejor eficacia de empaquetado prefijo en el mensaje saliente de BGP de actualización. La particionamiento BGP divide el nervio en varias subcostillas servidas por subprocesos RPD independientes. Por lo tanto, los prefijos que podían haber pasado en una única actualización saliente se acababan en particiones distintas. Para poder construir BGP actualizaciones con prefijos con el mismo atributo saliente que podría pertenecer a subprocesos con varias particiones RPD, todos los subprocesos con particiones envían información de anuncio compacto para que los prefijos se anuncien a un subproceso de actualización que atiende a ese grupo par BGP . Esto permite que el subproceso de actualización, que sirve a este par BGP grupo, empaque prefijos con los mismos atributos y que pueda pertenecer a distintas particiones en el mismo mensaje de actualización saliente. Esto minimiza el número de actualizaciones que se deben anunciar y, por lo tanto, ayuda a mejorar la convergencia. El subproceso de e/s gestiona las memorias caché locales de los recipientes de los interlocutores, grupos, prefijos, ETI y COSTILLAs.

El subproceso de BGP Update está deshabilitado de forma predeterminada. Si configura Update-Threading en un motor de enrutamiento, RPD crea subprocesos de actualización. De forma predeterminada, el número de subprocesos de actualización creados es el mismo que el número de núcleos de CPU del motor de enrutamiento. Los subprocesos de actualización solo se admiten en un proceso de protocolo de enrutamiento 64 bits (RPD). De manera opcional, puede especificar el número de subprocesos que desea crear mediante una set update-threading <number-of-threads> instrucción en el nivel [edit system processes routing bgp] de jerarquía. El rango está en la actualidad entre el 1 y el 128.

Descripción de BGP selección de trazado

Por cada prefijo de la tabla de enrutamiento, el proceso de protocolo de enrutamiento selecciona una sola ruta de acceso. Una vez seleccionada la mejor ruta, la ruta se instala en la tabla de enrutamiento. El mejor trazado se convierte en la ruta activa si un protocolo no aprende el mismo prefijo con un valor de preferencia global más bajo (más preferido), también conocido como distancia administrativa. El algoritmo para determinar la ruta activa es el siguiente:

  1. Compruebe que se puede resolver el siguiente salto.

  2. Seleccione la ruta con el valor de preferencia más bajo (preferencia de proceso de protocolo de enrutamiento).

    Las rutas que no pueden usarse para el reenvío (por ejemplo, porque la política de enrutamiento las rechazó o porque un salto siguiente no es inaccesible) tienen una preferencia de –1 y nunca se eligen.

  3. Preferir la ruta con mayor preferencia local.

    Para rutas BGP, elija la ruta con el valor preference2 más bajo.

  4. Si el atributo protocolo de puerta de enlace interior acumulable (AIGP) está habilitado, es preferible utilizar la ruta con el atributo AIGP inferior.

  5. Es preferible utilizar la ruta de acceso con el valor de la ruta de acceso más corta del as-path-ignore sistema autónomo (as) (omitido si la instrucción está configurada).

    Un segmento de la Confederación (secuencia o conjunto) tiene una longitud de ruta de acceso de 0. Un conjunto AS tiene una longitud de ruta de acceso de 1.

  6. Es preferible utilizar la ruta con el código de origen inferior.

    Las rutas aprendidas desde una IGP tienen un código de origen más bajo que las aprendidas de un protocolo de puerta de enlace exterior (EGP), y ambas tienen códigos de origen más bajos que rutas incompletas (rutas cuyo origen es desconocido).

  7. Es preferible utilizar la ruta con la métrica de discriminador de cierre múltiple (MED) más baja.

    Dependiendo de si se configura el comportamiento de selección de ruta de acceso de la tabla de enrutamiento no determinista, hay dos casos posibles:

    • Si no se configura el comportamiento de selección de rutas no deterministas de la ruta de la path-selection cisco-nondeterministic tabla de enrutamiento (es decir, si la instrucción no está incluida en la configuración del BGP), para los trazados con el mismo nivel de vecinos que los números en la parte frontal de la ruta as, se recomienda el trazado con el menor Med. coincide. Para comparar siempre MEDs si los interlocutores de las rutas comparadas son iguales, incluya el path-selection always-compare-med extracto.

    • Si se configura un comportamiento de selección de ruta de tabla de enrutamiento no determinista ( path-selection cisco-nondeterministic es decir, la instrucción se incluye en la configuración de la BGP), es preferible utilizar la ruta con la métrica mínima más baja.

    No se tienen en cuenta las confederaciones cuando se determinan las inmovilizaciones vecinas. Una métrica de MED ausente se trata como si hubiera un MED presente, pero cero.

    Nota:

    La comparación MED funciona en la selección de una sola ruta de acceso dentro de un AS (cuando la ruta no incluye una ruta AS), aunque este uso es poco común.

    De forma predeterminada, solo se comparan las MEDs de las rutas que tienen los mismos sistemas autónomos (Asoc) del mismo nivel. Puede configurar las opciones de selección de ruta de la tabla de enrutamiento para obtener distintos comportamientos.

  8. Es preferible utilizar rutas de IGP internas, que incluyen las rutas de la misma y las rutas generadas localmente (estáticas, directas, locales, etc.).

  9. Prefieras rutas de BGP estrictamente externas (EBGP) a través de rutas externas aprendidas a través de sesiones internas del BGP (IBGP).

  10. Es preferible utilizar la ruta cuyo siguiente salto se resuelva a través de la ruta de IGP con la métrica más baja.

    Nota:

    Un trazado se considera un BGP ruta de acceso de igual costo (y se utilizará para el reenvío) si se realiza una rotura de empates después del paso anterior. Se tienen en cuenta todos los paths en los que se encuentren los mismos vecinos que los que se han visto con varias rutas BGP vecinos.

    BGP multipath no se aplica a las rutas que comparten el mismo costo de MED-Plus-IGP todavía difieren en IGP costo. La selección de ruta de multipath se basa en la IGP métrica de costo, incluso si dos rutas tienen el mismo costo de MED-Plus-IGP.

    BGP compara el tipo de IGP métrica antes de comparar el valor de métrica en rt_metric2_cmpsí. Por ejemplo, BGP rutas que se resuelven a través de IGP son preferibles a las que se descartan, o RTM_TYPE_UNREACHrechaza los saltos siguientes que son del tipo. Estas rutas se declaran inactive a metric-typecausa de su.

  11. Si ambas trayectorias son externas, es preferible utilizar la ruta activa en ese momento para minimizar la oscilación de la ruta. Esta regla no se utiliza si se cumple alguna de las condiciones siguientes:

    • path-selection external-router-id está configurado.

    • Ambos interlocutores tienen el mismo identificador de enrutador.

    • Cualquiera de los interlocutores es un interlocutor del mismo nivel de la Confederación.

    • Ni la ruta de acceso es la ruta activa actual.

  12. Preferir una ruta principal a través de una ruta secundaria. Una ruta principal es la que pertenece a la tabla de enrutamiento. Una ruta secundaria es la que se agrega a la tabla de enrutamiento a través de una política de exportación.

  13. Prefiera la ruta de acceso del interlocutor con el identificador de enrutador más bajo. Para cualquier ruta de acceso con un atributo de identificador de originador, sustituya el identificador del originador del enrutador durante la comparación del ID del enrutador.

  14. Preferir la ruta de acceso con la longitud de lista de clúster más corta. La longitud es 0 para ninguna lista.

  15. Preferir la ruta de acceso del interlocutor con la dirección IP de menor nivel.

Selección de ruta de la tabla de enrutamiento

El valor predeterminado de la ruta de acceso del algoritmo evalúa de forma predeterminada la longitud de la ruta AS y determina el path activo. Puede configurar una opción que permita Junos OS omitir este paso del algoritmo incluyendo la as-path-ignore opción.

Nota:

A partir de Junos OS versión 14.1R8, 14.2R7, 15.1R4, 15.1F6 y 16.1R1, la as-path-ignore opción se admite para las instancias de enrutamiento.

La selección de la ruta del proceso de enrutamiento tiene lugar antes BGP entrega el trazado a la tabla de enrutamiento para tomar su decisión. Para configurar el comportamiento de selección de rutas de acceso path-selection de la tabla de enrutamiento, incluya la instrucción:

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

La selección de ruta de la tabla de enrutamiento se puede configurar de una de las siguientes maneras:

  • Emular el comportamiento predeterminado del Cisco IOS ( cisco-non-deterministic ). Este modo evalúa las rutas en el orden en que se reciben y no las agrupa de acuerdo con sus vecinos. Con cisco-non-deterministic Mode, el path activo es siempre el primero. Todos los paths inactivos, aunque válidos, siguen el path activo y se mantienen en el orden en el que se recibieron, con el path más reciente en primer lugar. Las rutas no aceptables permanecen al final de la lista.

    Como ejemplo, supongamos que tiene tres anuncios de ruta de acceso para la ruta 192.168.1.0/24:

    • Ruta 1: aprendida a través del EBGP; AS ruta de acceso de 65010; MED de 200

    • Ruta 2: aprendida a través del IBGP; AS ruta de acceso de 65020; MED de 150; IGP de 5

    • Ruta 3: aprendida a través del IBGP; AS ruta de acceso de 65010; MED de 100; IGP de 10

    Estos anuncios se reciben en breve sucesión, en un segundo, en el orden indicado. La ruta 3 se recibe más recientemente, por lo que el dispositivo de enrutamiento lo compara con la ruta 2, el siguiente anuncio más reciente. El costo de la IBGP del mismo nivel es mejor para la ruta 2, por lo que el dispositivo de enrutamiento elimina la contención de la ruta 3. Cuando se comparan los trazados 1 y 2, el dispositivo de enrutamiento prefiere la ruta 1 porque se recibe de un EBGP del mismo nivel. Esto permite que el dispositivo de enrutamiento Instale la ruta 1 como el path activo para la ruta.

    Nota:

    No se recomienda utilizar esta opción de configuración en su red. La interoperabilidad se proporciona únicamente para permitir que todos los dispositivos de enrutamiento de la red realicen selecciones de ruta coherentes.

  • Siempre comparando los MEDs, independientemente de si el par de AS de las rutas comparadas son los mismos ( always-compare-med ).

  • Invalide la regla de que si ambas rutas son externas, se prefiere la ruta actualmente activa ( external-router-id ). Continúe con el siguiente paso 12 (Paso) en el proceso de selección de ruta.

  • Agregar el costo de IGP al destino siguiente de salto hasta el valor MED antes de comparar los valores MED para la selecciónmed-plus-igpde path ().

    BGP multipath no se aplica a las rutas que comparten el mismo costo de MED-Plus IGP, pero difieren aún en IGP costo. La selección de ruta de multipath se basa en la IGP métrica de costo, incluso si dos rutas tienen el mismo costo de MED-Plus-IGP.

Selección de ruta de acceso de BGP tabla

Se siguen los siguientes parámetros para BGP selección de ruta:

  1. Preferir el valor más alto de preferencia local.

  2. Preferir la longitud de ruta más corta.

  3. Preferir el valor de origen más bajo.

  4. Es preferible utilizar el valor mínimo MED.

  5. Preferir las rutas aprendidas de EBGP igual sobre una IBGP del mismo nivel.

  6. Preferir mejor salida de AS.

  7. En el caso de las rutas recibidas por EBGP, preferir la ruta activa actual.

  8. Preferir las rutas del interlocutor con el identificador de enrutador más bajo.

  9. Rutas preferidas con la longitud de clúster más corta.

  10. Preferir rutas del interlocutor con la dirección IP de menor nivel. Los pasos 2, 6 y 12 son los criterios RPD.

Efectos de anunciar varios paths hacia un destino

BGP anuncia únicamente la ruta de acceso activa, a menos que configure BGP para que anuncie varias rutas a un destino.

Suponga que un dispositivo de enrutamiento tiene cuatro rutas de la tabla de enrutamiento a un destino y se ha configurado para que anuncieadd-path send path-count 3hasta tres rutas de la sesión (). Los tres trazados se eligen en función de los criterios de selección de trazados. Es decir, las tres rutas mejores se eligen en orden de selección de trazados. El mejor path es el path activo. Esta ruta de acceso se quita y se elige un nuevo camino mejor. Este proceso se repite hasta que se alcanza el número de rutas especificado.

Estándares compatibles para el BGP

Junos OS admite sustancialmente los siguientes RFC y borradores de Internet, los cuales definen estándares para la versión 4 de IP (IPv4) BGP.

Para obtener una lista de los estándares de BGP de IP versión 6 (IPv6) compatibles, consulte estándares de IPv6 compatibles.

Junos OS BGP admite autenticación para intercambios de protocolo (autenticación MD5).

  • RFC 1745, BGP4/IDRP para IP: interacción de OSPF

  • RFC 1772, aplicación de la protocolo de puerta de enlace de borde en Internet

  • RFC 1997, atributo de comunidades BGP

  • RFC 2283, multiprotocolo Extensions para BGP-4

  • RFC 2385, protección de sesiones de BGP mediante la opción de firma TCP MD5

  • RFC 2439, BGP amortiguación solapada de enrutamiento

  • RFC 2545, el uso de extensiones multiprotocolo BGP-4 para el enrutamiento entre dominios de IPv6

  • RFC 2796, BGP reflexión de ruta: una alternativa a la IBGP de malla completa

  • RFC 2858, multiprotocolo Extensions para BGP-4

  • RFC 2918, capacidad de enrutamiento actualizar para BGP-4

  • RFC 3065, confederaciones de sistema autónomas para BGP

  • RFC 3107, en el que se transporta información de etiquetas en BGP-4

  • RFC 3345, Protocolo de puerta de enlace de borde (BGP) condición de oscilación persistente de ruta

  • RFC 3392, anuncios de capacidades con BGP-4

  • RFC 4271, Protocolo de puerta de enlace de borde 4 (BGP-4)

  • RFC 4273, definiciones de objetos administrados para BGP-4

  • RFC 4360, atributo de BGP Extended Communities

  • RFC 4364, BGP/MPLS IP Virtual Private Networks (VPN)

  • RFC 4456, BGP reflexión de ruta: Una alternativa a la BGP interna de la malla completa (IBGP)

  • RFC 4486, subcódigos para BGP mensaje de notificación de cese

  • RFC 4659, extensión de red privada virtual (VPN) de BGP MPLS IP para VPN de IPv6

  • RFC 4632, enrutamiento entre dominios sin clase (EISC): El plan de asignación y agregación de direcciones de Internet

  • RFC 4684, distribución de rutas restringida para la conmutación de etiquetas por protocolo de puerta de enlace de borde/multiprotocolo (BGP/MPLS) protocolo de Internet (IP) Virtual Private Networks (VPN)

  • RFC 4724, mecanismo de reinicio correcto para BGP

  • RFC 4760, multiprotocolo Extensions para BGP-4

  • RFC 4781, mecanismo de reinicio correcto para BGP con MPLS

  • RFC 4798, conectar islas IPv6 a través de IPv4 MPLS mediante enrutadores perimetrales de proveedor IPv6 (6PE)

    Opción 4B (eBGP no se admite la redistribución de rutas IPv6 con etiquetas de al modo de vecinos como).

  • RFC 4893, BGP compatibilidad con un espacio de número de as de cuatro octetos

  • RFC 5004, evite BGP mejores transiciones de una dirección externa a otra

  • RFC 5065, confederaciones de sistema autónomas para BGP

  • RFC 5082, el mecanismo de seguridad generalizado TTL (GTSM)

  • RFC 5291, capacidad de filtrado de ruta saliente para BGP-4 (compatibilidad parcial)

  • RFC 5292, filtro de rutas salientes basadas en un prefijo de dirección para BGP-4 (compatibilidad parcial)

    Los dispositivos que ejecutan Junos OS pueden recibir mensajes de ORF basados en un prefijo.

  • RFC 5396, representación textual de números de sistema autónomo (as)

  • RFC 5492, anuncios de capacidades con BGP-4

  • RFC 5512, la encapsulación BGP un identificador de familia de direcciones (Safi) posterior y el atributo de encapsulación de túnel BGP

  • RFC 5549, anuncio de información de accesibilidad de IPv4 capa de red con un próximo salto IPv6

  • RFC 5575, difusión de las reglas de la especificación de flujo

  • RFC 5668, AS BGP comunidad extendida específica de 4 octetos

  • RFC 6286, Identificador de configuración único para todo el sistema autónomo BGP para BGP-4- totalmente compatible

  • RFC 6368, interno BGP como protocolo de borde de proveedor o cliente para redes privadas virtuales (VPN) BGP/MPLS IP

  • RFC 6810, la infraestructura de clave pública de recursos (RPKI) para el protocolo de enrutador

  • RFC 6811, BGP validación de origen de prefijo

  • RFC 6996, reserva de sistema autónomo (as) para uso privado

  • RFC 7300, reserva de los últimos números de sistema autónomo (as)

  • RFC 7752, distribución enlazada en extremo de la información de ingeniería de estado y de conexión del tráfico (Ing-T) mediante BGP

  • RFC 7854, Protocolo de monitoreo de BGP (BMP)

  • RFC 7911, anuncio de varias rutas en BGP

  • RFC 8212, Comportamiento de propagación de rutas BGP externos predeterminados (EBGP) sin cumplimiento total de políticas

    Excepciones:

    Los comportamientos de rfc 8212 no se implementan de forma predeterminada para evitar la interrupción de la configuración del cliente existente. El comportamiento predeterminado se mantiene para aceptar y anunciar todas las rutas con respecto a los pares del EBGP.

  • RFC 8326, cierre correcto de sesión BGP

  • Borrador de Internet draft-IDR-rfc8203bis-00, BGP la comunicación de apagado administrativo (caduca el 2018 de octubre)

  • Borrador de Internet draft-ietf-Grow-BMP-ADJ-rib-out-01, compatibilidad con las costillas de ajuste en el protocolo de monitoreo de BGP (BMP) (caduca el 3 de septiembre de 2018)

  • Borrador de Internet draft-ietf-IDR-aigp-06, el atributo de métricas de IGP acumulado para BGP (caduca el 2011 de diciembre)

  • Borrador de Internet draft-ietf-IDR-as0-06, codificación del procesamiento de as 0 (caduca el 2013 de febrero)

  • Borrador de Internet draft-ietf-IDR-Link-Bandwidth-06. txt, BGP comunidad con ancho de banda de vínculo extendido (caduca el 2013 de julio)

  • Borrador de Internet draft-ietf-Sidr-Origin-Validation-Signaling-00, BGP el prefijo de origen del estado de validación Comunidad ampliada (soporte parcial) (caduca el 2011 de mayo)

    La comunidad extendida (estado de validación de origen) se admite en Junos OS Directiva de enrutamiento. No se admite el cambio especificado en el procedimiento de selección de ruta.

  • Borrador de Internet draft-Kato-BGP-IPv6-link-local-00. txt, BGP4 + emparejamiento mediante dirección local de vínculo IPv6

Los siguientes documentos RFC y borrador de Internet no definen los estándares, pero proporcionan información acerca de BGP y las tecnologías relacionadas. El GTI-I los clasifica como "experimentales" o "de variously".

  • RFC 1965, confederaciones de sistema autónomas para BGP

  • RFC 1966, BGP Reflection de enrutamiento — una alternativa a la IBGP de malla completa

  • RFC 2270, con un as dedicado para sitios alojados en un solo proveedor

  • Borrador de Internet draft-ietf-ngtrans-BGP-Tunnel-04. txt, conectar islas IPv6 entre nubes IPv4 con BGP (caduca el 2002 de julio)

Tabla de historial de versiones
Liberación
Descripción
17.2R1
A partir de Junos OS versión de 17.2 en R1, el módulo de resolución de RPD está optimizado para aumentar el rendimiento del flujo de procesamiento de entrada, lo que acelera la velocidad de aprendizaje de las COSTILLAs y las FIB.
14.1R8
A partir de Junos OS versión 14.1R8, 14.2R7, 15.1R4, 15.1F6 y 16.1R1, la as-path-ignore opción se admite para las instancias de enrutamiento.