Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción general del BGP

Descripción del BGP

El BGP es un protocolo de puerta de enlace exterior (EGP) que se utiliza para intercambiar información de enrutamiento entre enrutadores de diferentes sistemas autónomos (AS). La información de enrutamiento del BGP incluye la ruta completa a cada destino. El BGP utiliza la información de enrutamiento para mantener una base de datos de información de accesibilidad de red, que intercambia con otros sistemas BGP. El BGP usa la información de accesibilidad de la red para construir un gráfico de conectividad del AS, lo que permite que el BGP elimine los bucles de enrutamiento y aplique las decisiones de política a nivel del AS.

Las extensiones del BGP multiprotocolo (MBGP) permiten que el BGP admita IP versión 6 (IPv6).MBGP define los atributos MP_REACH_NLRI y MP_UNREACH_NLRI, que se utilizan para transportar información de accesibilidad IPv6. Los mensajes de actualización de información de accesibilidad de la capa de red (NLRI) llevan prefijos de dirección IPv6 de rutas posibles.

El BGP permite el enrutamiento basado en políticas. Puede usar políticas de enrutamiento para elegir entre varias rutas a un destino y para controlar la redistribución de la información de enrutamiento.

El BGP usa TCP como protocolo de transporte y el puerto 179 para establecer conexiones. Ejecutar un protocolo de transporte confiable elimina la necesidad de que el BGP implemente la fragmentación de actualizaciones, la retransmisión, la confirmación y la secuenciación.

El software de protocolo de enrutamiento Junos OS es compatible con BGP versión 4. Esta versión del BGP agrega compatibilidad con enrutamiento entre dominios sin clase (EISC), lo que elimina el concepto de clases de red. En lugar de asumir qué bits de una dirección representan la red mirando el primer octeto, EISC le permite especificar explícitamente el número de bits en la dirección de red, proporcionando así un medio para reducir el tamaño de las tablas de enrutamiento. La versión 4 del BGP también admite la agregación de rutas, incluida la agregación de rutas de AS.

En esta sección se analizan los siguientes temas:

Sistemas autónomos

Un sistema autónomo (AS) es un conjunto de enrutadores que están bajo una única administración técnica y normalmente utilizan un protocolo de puerta de enlace interior único y un conjunto común de métricas para propagar la información de enrutamiento dentro del conjunto de enrutadores. Para otros AS, un AS parece tener un plan de enrutamiento interior único y coherente y presenta una imagen coherente de a qué destinos se puede llegar a través de él.

Rutas y atributos del AS

La información de enrutamiento que intercambian los sistemas BGP incluye la ruta completa a cada destino, así como información adicional sobre la ruta. La ruta a cada destino se denomina ruta del AS y la información de ruta adicional se incluye en los atributos de ruta. El BGP usa la ruta del AS y los atributos de ruta para determinar por completo la topología de red. Una vez que el BGP entiende 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 política de enrutamiento.

BGP externo e interno

El BGP admite dos tipos de intercambios de información de enrutamiento: intercambios entre diferentes AS e intercambios dentro de un único AS. Cuando se utiliza en AS, el BGP se denomina BGP externo (EBGP) y las sesiones de BGP realizan enrutamiento entre AS. Cuando se utiliza en un AS, el BGP se denomina BGP interno (IBGP) y las sesiones de BGP realizan enrutamiento intraAS. Figura 1 ilustra las AS, IBGP y EBGP.

Figura 1: AS, EBGP e IBGPAS, EBGP e IBGP

Un sistema BGP comparte información de accesibilidad de red con sistemas BGP adyacentes, a los que se les conoce como vecinos o pares.

Los sistemas BGP se organizan en grupos. En un grupo de IBGP, todos los pares del grupo ( denominados pares internos) están en el mismo AS. Los pares internos pueden estar en cualquier parte del AS local y no tienen que estar conectados directamente entre sí. Los grupos internos usan rutas desde un IGP para resolver direcciones de reenvío. También propagan rutas externas entre todos los otros enrutadores internos que ejecutan IBGP, calculando el siguiente salto tomando el BGP siguiente salto recibido con la ruta y resolviendolo usando la información de 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 que se comparte entre el par externo y el enrutador local.

Varias instancias de BGP

Puede configurar varias instancias de BGP en los siguientes niveles jerárquicos:

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

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

Se utilizan principalmente varias instancias de BGP para admitir VPN de capa 3.

Los pares de IGP y los pares de BGP externos (EBGP) (ambos no multihop y multihop) son compatibles con las instancias de enrutamiento. El emparejamiento del BGP se establece en una de las interfaces configuradas en la routing-instances jerarquía.

Nota:

Cuando un vecino del BGP envía mensajes de BGP al dispositivo de enrutamiento local, la interfaz de entrada en la que se reciben estos mensajes debe estar configurada en la misma instancia de enrutamiento en la que existe la configuración de vecino del BGP. Esto es cierto para los vecinos que están a un solo salto de distancia o varios saltos de distancia.

Las rutas aprendidas del par BGP se agregan a la instance-name.inet.0 tabla de forma predeterminada. Puede configurar políticas de importación y exportación para controlar el flujo de información hacia y hacia fuera de la tabla de enrutamiento de instancias.

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

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

Puede configurar una sesión multihop de EBGP para una instancia de enrutamiento VRF. Además, puede configurar el par EBGP entre los enrutadores PE y CE mediante el uso de la dirección de circuito cerrado del enrutador CE en lugar de las direcciones de interfaz.

Permitir tráfico de protocolo para interfaces en una zona de seguridad

En los dispositivos de la serie SRX, debe habilitar el tráfico entrante de host esperado en las interfaces especificadas o en todas las interfaces de la zona. De lo contrario, el tráfico entrante destinado a este dispositivo se pierde de forma predeterminada.

Por ejemplo, para permitir el tráfico del BGP en una zona específica de su dispositivo serie SRX, utilice el siguiente paso:

(Todas las interfaces) (Interfaz especificada)

Descripción general de rutas de BGP

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

La siguiente información describe la ruta:

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

  • Atributos de ruta, que contienen información adicional acerca de la ruta del AS que se utiliza en la política de enrutamiento.

Los pares del BGP anuncian rutas entre sí en mensajes de actualización.

El BGP almacena sus rutas en la tabla de enrutamiento de Junos OS (inet.0). La tabla de enrutamiento almacena la siguiente información acerca de las rutas BGP:

  • Información de enrutamiento aprendida de los mensajes de actualización recibidos de los pares

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

  • Información que el BGP anuncia a sus pares en los mensajes de actualización

Para cada prefijo de la tabla de enrutamiento, el proceso de protocolo de enrutamiento selecciona una única mejor ruta, denominada ruta activa. A menos que configure el BGP para anunciar varias rutas al mismo destino, el BGP anuncia solo la ruta activa.

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

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

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

  • 2— Se desconoce el origen de la ruta.

Descripción general de la resolución de ruta del BGP

Una ruta interna de BGP (IBGP) con una dirección de salto siguiente a un vecino de BGP remoto (protocolo de salto siguiente) debe tener su siguiente salto resuelto mediante alguna otra ruta. El 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 siguiente salto del BGP se resuelve mediante la ruta de entrada RSVP. Esto da como resultado que la ruta del BGP apunte a un siguiente salto indirecto y que el siguiente salto indirecto apunte a un siguiente salto de reenvío. El siguiente salto de reenvío se deriva del salto siguiente de la ruta RSVP. A menudo hay un gran conjunto de rutas de BGP internas que tienen el mismo protocolo siguiente salto, y en tales casos, el conjunto de rutas BGP haría referencia al mismo salto indirecto siguiente.

Antes de la versión 17.2R1 de Junos OS, el módulo de resolución del proceso de protocolo de enrutamiento (rpd) resolvió las rutas recibidas dentro del IBGP de las siguientes maneras:

  1. Resolución de ruta parcial: el siguiente salto del protocolo se resuelve en función de rutas auxiliares, como rutas RSVP o IGP. Los valores de la métrica se derivan de las rutas del ayudante y el siguiente salto se denomina salto siguiente como el salto siguiente de reenvío de resolución heredado de las rutas del ayudante. 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 de ruta completa: se deriva el último salto siguiente y se denomina tabla de enrutamiento de kernel (KRT) que se reenvía al siguiente salto según la política de exportación de reenvío.

A partir de Junos OS versión 17.2R1, el módulo de resolución de rpd está optimizado para aumentar la transferencia de datos del flujo de procesamiento entrante, acelerando la velocidad de aprendizaje de RIB y FIB. Con esta mejora, la resolución de ruta se ve afectada de la siguiente manera:

  • Los métodos de resolución de ruta parcial y completa se activan para cada ruta ibgp, aunque es posible que cada ruta herede el mismo reenvío resuelto en el próximo salto o en krT próximos saltos.

  • La selección de ruta del BGP se posterga hasta que se realice la resolución completa de la ruta para la información de accesibilidad de la capa de red (NLRI) recibida de un vecino del BGP, que puede no ser la mejor ruta en el RIB después de la selección de ruta.

Los beneficios de la optimización de la resolución rpd incluyen:

  • Menor costo de búsqueda de resolución RIB: el resultado de la ruta resuelta se guarda en una caché de resolución, de modo que se puedan heredar los mismos valores de métrica y salto siguiente derivados a otro conjunto de rutas que compartan el mismo comportamiento de ruta en lugar de realizar un flujo de resolución de ruta parcial y completo. 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 profundidad limitada.

  • Optimización de la selección de rutas del BGP: el algoritmo de selección de ruta del BGP se activa dos veces por cada ruta ibgp recibida; en primer lugar, mientras se agrega la ruta en el RIB con el siguiente salto como inutilizable y, en segundo lugar, se agrega la ruta con un salto siguiente resuelto en el RIB (después de la resolución de ruta). El resultado es seleccionar la mejor ruta dos veces. Con la optimización de resolución, el proceso de selección de ruta se activa en el flujo de recepción solo después de obtener la información del siguiente salto del módulo de resolución.

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

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

Descripción general de mensajes de BGP

Todos los mensajes del BGP tienen el mismo encabezado de tamaño fijo, el cual 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 analizan los siguientes temas:

Mensajes abiertos

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

Los mensajes abiertos constan del encabezado del BGP más los siguientes campos:

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

  • Número de AS local: esto se configura incluyendo la autonomous-system instrucción en el [edit routing-options] nivel de jerarquía o [edit logical-systems logical-system-name routing-options] .

  • Tiempo de espera: valor de tiempo de espera propuesto. Configure el tiempo de espera local con la instrucción BGP hold-time .

  • Identificador BGP: dirección IP del sistema BGP. Esta dirección se determina cuando se inicia el sistema y es la misma para cada interfaz local y cada par de BGP. Puede configurar el identificador del BGP incluyendo la router-id instrucción en el [edit routing-options] nivel de jerarquía o [edit logical-systems logical-system-name routing-options] . De forma predeterminada, el BGP usa la dirección IP de la primera interfaz que encuentra en el enrutador.

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

Mensajes de actualización

Los sistemas BGP envían mensajes de actualización para intercambiar información de accesibilidad de la red. Los sistemas BGP usan esta información para construir un gráfico que describe las relaciones entre todos los AS conocidos.

Los mensajes de actualización constan del encabezado del BGP más los siguientes campos opcionales:

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

  • Rutas retiradas: prefijos de dirección IP para las rutas que se retiran del servicio porque ya no se las considera accesibles

  • Longitud total del atributo de ruta: longitud del campo de atributos de ruta; enumera los atributos de ruta para una ruta factible a 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 por la ruta e información sobre agregación, comunidades, confederaciones y reflexión de rutas

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

Mensajes de keepalive

Los sistemas BGP intercambian mensajes de mantención para determinar si un vínculo o host ha fallado o ya no está disponible. Los mensajes de keepalive se intercambian con la suficiente frecuencia para que el temporizador de espera no expire. Estos mensajes constan solo del encabezado del 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, la sesión del BGP y la conexión TCP entre los sistemas BGP se cierran. Los mensajes de notificación constan del encabezado del BGP más el código de error y el subcódigo, y los datos que describen el error.

Mensajes de actualización de ruta

Los sistemas BGP envían mensajes de actualización de ruta a un par solo si han recibido el anuncio de capacidad de actualización de ruta del par. Un sistema BGP debe anunciar la capacidad de actualización de ruta a sus pares mediante el anuncio de capacidades del BGP si desea recibir mensajes de actualización de ruta. Este mensaje opcional se envía para solicitar actualizaciones de rutas dinámicas, entrantes y de BGP a los pares del BGP o para enviar actualizaciones de ruta saliente 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 ignorarlo el receptor.

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

Si un par sin la capacidad de actualización de ruta recibe un mensaje de solicitud de actualización de ruta de un par remoto, el receptor ignora el mensaje.

Descripción de la fragmentación RIB del BGP y la actualización del hilo de E/S del BGP

El procesamiento de ruta del BGP generalmente tiene varias etapas de canalización, como recepción de actualización, análisis de actualización, creación de ruta, resolución del salto siguiente, aplicación de la política de exportación de un grupo par de BGP, formación de actualizaciones por par y envío de actualizaciones a pares.

La fragmentación RIB del BGP divide un RIB de BGP unificado en varias sub-RIB y cada sub-RIB maneja un subconjunto de rutas BGP. El subproceso RPD denominado subproceso de fragmentación BGP sirve a cada sub-RIB para lograr la simultaneidad. Los subprocesos de fragmentación del BGP son responsables de todas las etapas de la canalización de ruta del BGP, con la excepción de formar actualizaciones por par y enviar actualizaciones a pares. Los subprocesos de partición del BGP reciben las actualizaciones enviadas por los pares desde los subprocesos de E/S de BGP Update con los subprocesos de E/S de BGP Update que hashan los prefijos de las actualizaciones y las envía a los subprocesos de fragmentos del BGP correspondientes según el cálculo hash. El subproceso de partición del BGP procesa la configuración de la misma manera que el subproceso principal RPD, crea pares, grupos, tablas de ruta y utiliza la información de configuración para el procesamiento de rutas del BGP.

Los subprocesos de E/S de actualización del BGP son responsables del extremo final de esta canalización de BGP, lo que implica generar actualizaciones por par para grupos de BGP individuales y enviarlos a los pares. Un subproceso de actualización puede servir a uno o más grupos de BGP. Los subprocesos de E/S de actualización del BGP construyen actualizaciones para grupos en paralelo e independientes de otros grupos a los que otros subprocesos de actualización están siendo atendidos. Esto podría ofrecer una mejora significativa de la convergencia en una carga de trabajo con mucha escritura, que implica publicidad a muchos pares repartidos en muchos grupos. Los subprocesos de E/S de BGP Update también se encargan de escribir y leer desde los sockets TCP de los pares del BGP, que anteriormente proporcionaban los subprocesos BGPIO (de ahí el sufijo IO en BGP Update IO).

Los subprocesos de E/S de la actualización del BGP se pueden configurar independientemente de la función de fragmentación RIB, pero son obligatorios para su uso con la fragmentación rib, con el fin de lograr una mejor eficiencia de embalaje de prefijos en el mensaje de actualización del BGP saliente. La fragmentación del BGP divide el RIB en varias sub RIB que se sirven mediante subprocesos RPD. Por lo tanto, los prefijos que podrían haber entrado en una sola actualización saliente terminan en fragmentos diferentes. Para poder construir actualizaciones de BGP con prefijos con el mismo atributo de salida que podrían pertenecer a subprocesos de partición RPD diferentes, todos los subprocesos de partición envían información publicitaria compacta de los prefijos que se anunciarán a una actualización de subproceso que sirve a ese grupo par del BGP. Esto permite que el subproceso de actualización, que sirve a este grupo par del BGP, empaquetara prefijos con los mismos atributos, que potencialmente pertenecen a diferentes fragmentos en el mismo mensaje de actualización saliente. Esto minimiza la cantidad de actualizaciones que se anunciarán y, por lo tanto, ayuda a mejorar la convergencia. Actualizar el hilo de E/S administra las cachés locales de los contenedores de par, grupo, prefijo, TSI y RIB.

El subproceso de actualización del BGP y la fragmentación RIB de BGP están deshabilitados de forma predeterminada. Si configura update-threading y rib-sharding en un motor de enrutamiento, RPD crea subprocesos de actualización. De forma predeterminada, la cantidad de subprocesos de actualización y subprocesos de fragmentación creados es el mismo que el número de núcleos de CPU en el motor de enrutamiento. La actualización de subprocesos solo se admite en un proceso de protocolo de enrutamiento (rpd) de 64 bits. Opcionalmente, puede especificar el número de subprocesos que desea crear mediante el uso set update-threading <number-of-threads> y set rib-sharding <number-of-threads> las instrucciones en el [edit system processes routing bgp] nivel de jerarquía. En el caso del subproceso de actualización del BGP, el rango es actualmente del 1 al 128 y para el particionamiento RIB del BGP, el rango es actualmente del 1 al 31.

Cuando configure NSR para las funciones de fragmentación RIB de BGP y actualización de E/S del BGP, el RPD de copia de seguridad crea la misma cantidad de subprocesos de E/S de BGP y actualización de BGP en el motor de enrutamiento de respaldo. Los subprocesos de actualización del BGP de RPD de copia de seguridad leen la actualización del BGP replicada, otros mensajes recibidos de los pares, así como la actualización del BGP replicada, y otros mensajes enviados a los pares. Según el hash de los prefijos, los subprocesos de EO de actualización del BGP rpd de copia de seguridad envían estos mensajes de BGP a los subprocesos principales de BGP y RPD correspondientes. El fragmento del BGP y los subprocesos principales de RPD en el RPD de copia de seguridad crean el estado de la ruta recibida y anunciada mediante estos mensajes de BGP replicados. Cuando el motor de enrutamiento principal falla, el motor de enrutamiento de respaldo se convierte en el motor de enrutamiento principal y el RPD de respaldo se convierte en el RPD principal sin problemas sin afectar las sesiones de BGP con los pares.

Descripción de la selección de ruta del BGP

Para cada prefijo de la tabla de enrutamiento, el proceso de protocolo de enrutamiento selecciona una única mejor ruta. Después de seleccionar la mejor ruta, la ruta se instala en la tabla de enrutamiento. La mejor ruta 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. Elija la ruta con el valor de preferencia más bajo (preferencia de proceso de protocolo de enrutamiento).

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

  3. Prefiera la ruta con mayor preferencia local.

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

  4. Si el atributo del protocolo de puerta de enlace interior acumulado (AIGP) está habilitado, prefiera la ruta con el atributo AIGP inferior.

  5. Prefiera la ruta con el valor de ruta de sistema autónomo (AS) más corto (omitido si la as-path-ignore instrucción está configurada).

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

  6. Prefiera la ruta con el código de origen inferior.

    Las rutas aprendidas de un IGP tienen un código de origen menor que las aprendidas de un protocolo de puerta de enlace exterior (EGP), y ambas tienen códigos de origen más bajos que las rutas incompletas (rutas cuyo origen se desconoce).

  7. Prefiera la ruta con la métrica discriminatoria de salida múltiple (MED) más baja.

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

    • Si el comportamiento de selección de rutas de la tabla de enrutamiento no determinista no está configurado (es decir, si la path-selection cisco-nondeterministic instrucción no está incluida en la configuración del BGP), en el caso de las rutas con los mismos números de AS vecinos en la parte frontal de la ruta del AS, prefiera la ruta con la métrica MED más baja. Para comparar siempre los MED, ya sea que el par de AS de las rutas comparadas sea o no el mismo, incluya la path-selection always-compare-med instrucción.

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

    Las confederaciones no se tienen en cuenta a la hora de determinar los AS vecinos. Una métrica MED faltante se trata como si un MED estuviera presente pero cero.

    Nota:

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

    De forma predeterminada, solo se comparan los MED de las rutas que tienen los mismos sistemas autónomos par (AS). Puede configurar las opciones de selección de rutas de la tabla de enrutamiento para obtener diferentes comportamientos.

  8. Prefiera rutas estrictamente internas, que incluyen rutas IGP y rutas generadas localmente (estáticas, directas, locales, etc.).

  9. Prefiera las rutas estrictamente externas de BGP (EBGP) sobre las rutas externas aprendidas a través de sesiones de BGP internas (IBGP).

  10. Prefiere la ruta cuyo siguiente salto se resuelve mediante la ruta IGP con la métrica más baja.

    Nota:

    Una ruta se considera una ruta de costo igual de BGP (y se utilizará para el reenvío) si se realiza un desempate después del paso anterior. Se consideran todas las rutas con el mismo AS vecino aprendidas por un vecino del BGP habilitado para varias rutas.

    La multiruta del BGP no se aplica a rutas que comparten el mismo costo MED-plus-IGP, pero difieren en el costo de IGP. La selección de rutas multiruta se basa en la métrica de costo del IGP, incluso si dos rutas tienen el mismo costo med-plus-IGP.

    El BGP compara el tipo de métrica IGP antes de comparar el valor de la métrica en rt_metric2_cmp. Por ejemplo, se prefieren las rutas del BGP que se resuelven mediante IGP a los próximos saltos descartados o rechazados que son de tipo RTM_TYPE_UNREACH. Estas rutas se declaran inactive debido a su metric-type.

  11. Si ambas rutas son externas, prefiera la ruta actualmente activa para minimizar la flaqueo de rutas. Esta regla no se utiliza si se cumple alguna de las condiciones siguientes:

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

    • Ambos pares tienen el mismo ID de enrutador.

    • Cualquiera de los dos es un par de confederación.

    • Ninguna de las rutas es la ruta activa actual.

  12. Prefiera una ruta principal en lugar de una ruta secundaria. Una ruta principal es aquella que pertenece a la tabla de enrutamiento. Una ruta secundaria es aquella que se agrega a la tabla de enrutamiento mediante una política de exportación.

  13. Prefiera la ruta del par con el ID de enrutador más bajo. Para cualquier ruta con un atributo id. de origen, sustituya el ID del originador por el ID de enrutador durante la comparación del ID del enrutador.

  14. Prefiera la ruta con la longitud de la lista de clústeres más corta. La longitud es 0 para ninguna lista.

  15. Prefiera la ruta del par con la dirección IP del par más bajo.

Selección de ruta de tabla de enrutamiento

El paso de la ruta del AS más corto del algoritmo, de forma predeterminada, evalúa la longitud de la ruta del AS y determina la ruta activa. Puede configurar una opción que permita que Junos OS omita 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 instancias de enrutamiento.

La selección de ruta del proceso de enrutamiento se lleva a cabo antes de que el BGP despega la ruta a la tabla de enrutamiento para tomar su decisión. Para configurar el comportamiento de selección de ruta de la tabla de enrutamiento, incluya la path-selection instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

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

  • Emule el comportamiento predeterminado de Cisco IOS (cisco-non-deterministic). Este modo evalúa las rutas en el orden en que se reciben y no las agrupa según sus AS vecinos. Con cisco-non-deterministic el modo, la ruta activa siempre es la primera. Todas las rutas inactivas, pero elegibles, siguen la ruta activa y se mantienen en el orden en que se recibieron, con la ruta más reciente primero. Las rutas no elegibles permanecen al final de la lista.

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

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

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

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

    Estos anuncios se reciben en rápida sucesión, en un segundo, en el orden indicado. La ruta 3 se recibió más recientemente, por lo que el dispositivo de enrutamiento la compara con la ruta 2, el siguiente anuncio más reciente. El costo para el par IBGP es mejor para la ruta 2, por lo que el dispositivo de enrutamiento elimina la ruta 3 de la contención. Al comparar las rutas 1 y 2, el dispositivo de enrutamiento prefiere la ruta 1 porque se recibe de un par ebGP. Esto permite que el dispositivo de enrutamiento instale la ruta 1 como la ruta activa de la ruta.

    Nota:

    No recomendamos usar esta opción de configuración en la red. Se proporciona únicamente para la interoperabilidad para permitir que todos los dispositivos de enrutamiento de la red realicen selecciones de rutas coherentes.

  • Siempre comparando los MED, ya sea que el par de AS de las rutas comparadas sea o no el mismo (always-compare-med).

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

  • Agregar el costo de IGP al destino del siguiente salto al valor MED antes de comparar los valores MED para la selección de ruta (med-plus-igp).

    La multiruta del BGP no se aplica a las rutas que comparten el mismo costo med-plus-IGP, pero difieren en el costo de IGP. La selección de rutas multiruta se basa en la métrica de costo del IGP, incluso si dos rutas tienen el mismo costo med-plus-IGP.

Selección de ruta de tabla BGP

Se siguen los siguientes parámetros para la selección de rutas del BGP:

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

  2. Prefiere la longitud de la ruta del AS más corta.

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

  4. Prefiera el valor MED más bajo.

  5. Prefiera las rutas aprendidas de un par EBGP en lugar de un par de IBGP.

  6. Prefiera la mejor salida del AS.

  7. Para las rutas recibidas del EBGP, prefiera la ruta activa actual.

  8. Prefiera las rutas del par con el ID de enrutador más bajo.

  9. Prefiera las rutas con la longitud de clúster más corta.

  10. Prefiera las rutas del par con la dirección IP del par más bajo. Los pasos 2, 6 y 12 son los criterios rpd.

Efectos de anunciar varias rutas a un destino

El BGP anuncia solo la ruta activa, a menos que configure el BGP para anunciar varias rutas a un destino.

Supongamos que un dispositivo de enrutamiento tiene en su tabla de enrutamiento cuatro rutas a un destino y está configurado para anunciar hasta tres rutas (add-path send path-count 3). Las tres rutas se eligen según los criterios de selección de rutas. Es decir, las tres mejores rutas se eligen en orden de selección de rutas. La mejor ruta es la ruta activa. Esta ruta se elimina de consideración y se elige una nueva mejor ruta. Este proceso se repite hasta que se alcanza el número especificado de rutas.

Estándares compatibles para BGP

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

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

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

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

  • RFC 1772, Aplicación del protocolo de puerta de enlace de borde en Internet

  • RFC 1997, Atributo de comunidades BGP

  • RFC 2283, Extensiones multiprotocolo para BGP-4

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

  • RFC 2439, Atenuación de solapa de ruta BGP

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

  • RFC 2796, Reflexión de ruta del BGP: una alternativa al IBGP de malla completa

  • RFC 2858, Extensiones multiprotocolo para BGP-4

  • RFC 2918, Capacidad de actualización de ruta para BGP-4

  • RFC 3065, Confederaciones De Sistema Autónomo para BGP

  • RFC 3107, Información de etiquetas de transporte en BGP-4

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

  • RFC 3392, Anuncio 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 comunidades extendidas del BGP

  • RFC 4364, Redes privadas virtuales IP BGP/MPLS (VPN)

  • RFC 4456, Reflexión de ruta del BGP: Una alternativa al BGP interno de malla completa (IBGP)

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

  • RFC 4659, Extensión de red privada virtual (VPN) IP BGP-MPLS para VPN 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 ruta restringida para protocolo de puerta de enlace de borde/conmutación de etiquetas multiprotocolo (BGP/MPLS) Protocolo de Internet (IP) Redes privadas virtuales (VPN)

  • RFC 4724, Mecanismo de reinicio elegante para BGP

  • RFC 4760, Extensiones multiprotocolo para BGP-4

  • RFC 4781, Mecanismo de reinicio agraciado para BGP con MPLS

  • RFC 4798, conexión de islas IPv6 a través de MPLS IPv4 mediante enrutadores de borde de proveedor IPv6 (6PE)

    No se admite la opción 4b (redistribución de eBGP de rutas IPv6 etiquetadas del AS al AS vecino).

  • RFC 4893, Soporte del BGP para espacio de número del AS de cuatro octetos

  • RFC 5004, Evite las transiciones de la mejor ruta del BGP de un externo a otro

  • RFC 5065, Confederaciones del Sistema Autónomo para BGP

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

  • RFC 5291, Capacidad de filtrado de ruta saliente para BGP-4 (soporte parcial)

  • RFC 5292, Filtro de ruta de salida basado en prefijos de dirección para BGP-4 (soporte parcial)

    Los dispositivos que ejecutan Junos OS pueden recibir mensajes ORF basados en prefijos.

  • RFC 5396, Representación textual de números de sistema autónomo (AS)

  • RFC 5492, Anuncio de capacidades con BGP-4

  • RFC 5512, El identificador de familia de direcciones posteriores de encapsulación del BGP (SAFI) y el atributo de encapsulación de túnel BGP

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

  • RFC 5575, Difusión de reglas de especificación de flujo

  • RFC 5668, Comunidad extendida específica del AS de 4 octetos

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

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

  • RFC 6810, La infraestructura de clave pública de recursos (RPKI) al protocolo de enrutador

  • RFC 6811, Validación de origen del prefijo BGP

  • RFC 6996, Reserva de sistema autónomo (AS) para uso privado

  • RFC 7300, Reserva de números del último sistema autónomo (AS)

  • RFC 7611, BGP ACCEPT_OWN atributo de comunidad

    Apoyamos la RFC al permitir que los enrutadores de Juniper acepten rutas recibidas de un reflector de ruta con el valor de la accept-own comunidad.

  • RFC 7752, Distribución en dirección norte de información de estado de vínculo y de ingeniería de tráfico (TE) mediante BGP

  • RFC 7854, Protocolo de monitoreo BGP (BMP)

  • RFC 7911, Anuncio de varias rutas en el BGP

  • RFC 8212, Comportamiento predeterminado de propagación de ruta del BGP externo (EBGP) sin políticas: completamente compatibles con las políticas

    Excepciones:

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

  • RFC 8326, Apagado elegante de la sesión del BGP

  • RFC 9069, Soporte para RIB local en el protocolo de monitoreo del BGP (BMP)

  • Borrador de Internet draft-idr-rfc8203bis-00, Comunicación de cierre administrativo del BGP (caduca en octubre de 2018)

  • Borrador de Internet draft-ietf-grow-bmp-adj-rib-out-01, Soporte para Adj-RIB-Out en el protocolo de monitoreo del BGP (BMP) (vence el 3 de septiembre de 2018)

  • Borrador de Internet draft-ietf-idr-aigp-06, El atributo de métrica de IGP acumulado para BGP (caduca en diciembre de 2011)

  • Borrador de Internet draft-ietf-idr-as0-06, Codificación del procesamiento del AS 0 (caduca en febrero de 2013)

  • Borrador de Internet draft-ietf-idr-link-bandwidth-06.txt, BGP Link Bandwidth Extended Community (caduca en julio de 2013)

  • Borrador de Internet draft-ietf-sidr-origin-validation-signaling-00, Prefijo BGP Validación de origen Estado extendido comunidad (soporte parcial) (caduca en mayo de 2011)

    La comunidad extendida (estado de validación de origen) se admite en la política de enrutamiento de Junos OS. 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, emparejamiento BGP4+ usando dirección de enlace IPv6

Los siguientes RFC y borradores de Internet no definen estándares, sino que proporcionan información sobre BGP y tecnologías relacionadas. El IETF los clasifica de varias formas como "experimentales" o "informativos".

  • RFC 1965, Confederaciones de Sistema Autónomo para BGP

  • RFC 1966, Reflexión de ruta del BGP: una alternativa al IBGP de malla completa

  • RFC 2270, Uso de un AS dedicado para sitios albergados a un único proveedor

  • Borrador de Internet draft-ietf-ngtrans-bgp-tunnel-04.txt, Conexión de islas IPv6 a través de nubes IPv4 con BGP (caduca en julio de 2002)

Tabla de historial de versiones
Liberación
Descripción
17.2R1
A partir de Junos OS versión 17.2R1, el módulo de resolución de rpd está optimizado para aumentar la transferencia de datos del flujo de procesamiento entrante, acelerando la velocidad de aprendizaje de RIB y 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 instancias de enrutamiento.