CCNP - and - CCIE - Enterprise - Core - CAPITULO - 11 ES

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 69

CAPÍTULO 11

BGP

Este capítulo abarca los siguientes temas:


Fundamentos de BGP: Esta sección proporciona una visión general de los
fundamentos del protocolo de enrutamiento BGP.

Configuración básica de BGP: Esta sección recorre el proceso de configuración de BGP


para establecer una sesión vecina y cómo se intercambian las rutas entre los peers.

Resumen de rutas: Esta sección proporciona una visión general de cómo funciona la
integración de rutas con BGP y algunas de las consideraciones de diseño con la
integración.

flultiprotocolo BGP para IPv6: Esta sección explica cómo BGP proporciona soporte para
el enrutamiento y la configuración de IPv6.

El RFC 1654 define el Border Gateway Protocol (BGP) como un protocolo de enrutamiento
vectorial de ruta estandarizado EGP que proporciona escalabilidad, flexibilidad y
estabilidad de red. Cuando se creó BGP, la principal consideración de diseño fue para la
conectividad entre organizaciones IPv4 en redes públicas como Internet y en redes privadas
dedicadas. BGP es el único proto- col que se utiliza para intercambiar redes en Internet, que
cuenta con más de 780.000 rutas IPv4 y sigue creciendo. Debido al gran tamaño de las tablas
BGP, BGP no anuncia actualizaciones incrementales ni refresca los anuncios de red como
hacen OSPF e IS-IS. BGP prefiere la estabilidad dentro de la red, ya que un flap de enlace
podría provocar el cálculo de rutas para miles de rutas.
Este capítulo cubre los fundamentos de BGP (atributos de ruta, familias de direcciones y
comunicación entre enrutadores), la configuración de BGP, el resumen de rutas y el soporte
para IPv6. En el capítulo 12, "BGP avanzado", se explican los escenarios más comunes en
entornos empresariales para BGP, el filtrado y la manipulación de rutas, las comunidades
BGP y la lógica que utiliza BGP para identificar una ruta como la mejor.

"¿Ya sé esto?" Cuestionario


El cuestionario "¿Ya sé esto?" le permite evaluar si debe leer todo el capítulo. Si no falla en
más de una de estas preguntas de autoevaluación, podría
para pasar a la sección "Tareas de preparación del examen". La Tabla 11-1 enumera los
principales títulos de este capítulo y las preguntas del cuestionario "¿Ya sé esto?" que
cubren el material de
para que pueda evaluar sus conocimientos en estas áreas específicas. Las respuestas al
cuestionario "¿Ya lo sé?" aparecen en el Apéndice A, "Respuestas al cuestionario "¿Ya lo sé?
Preguntas del cuestionario".
Tabla 11-1 "¿Ya sé esto? "Sección de Temas Fundamentales a la pregunta
Sección de Temas Fundamentales Preguntas
Fundamentos de BGP 1–4
Configuración básica de BGP 5–8
Resumen de la ruta 9
BGP multiprotocolo para IPv6 10

1. ¿Cuáles de los siguientes sistemas autónomos son privados? (Elija dos.)


a. 64,512–65,535
b. 65,000–65,535
c. 4,200,000,000–4,294,967,294
d. 4,265,000–4,265,535,016
2. ¿Qué atributo de BGP debe ser reconocido por todas las implementaciones de BGP
y anunciado a otros sistemas autónomos?
a. Conocida como obligatoria
b. Conocida discrecionalidad
c. Transitivo opcional
d. Opcional no transitivo
3. Verdadero o falso: BGP soporta el descubrimiento dinámico de vecinos por parte de ambos routers.
a. Verdadero
b. Falso
4. Verdadero o falso: Una sesión BGP siempre está a un salto de un vecino.
a. Verdadero
b. Falso
5. Verdadero o falso: La familia de direcciones IPv4 debe ser inicializada para
establecer una sesión BGP con un peer que utilice direccionamiento IPv4.
a. Verdadero
b. Falso
6. ¿Qué comando se utiliza para ver los vecinos de BGP y sus intervalos hello?
a. show bgp neighbors
b. show bgp afi safi vecinos
c. show bgp afi safi resumen
d. show afi bgp interface brief
7. ¿Cuántas tablas utiliza BGP para almacenar prefijos?
a. Una
b. Dos
c. Tres
d. Cuatro
Capítulo 11: BGP 242

8. Verdadero o falso: BGP anuncia todas sus rutas para cada prefijo de manera que
cada vecino pueda construir su propia tabla de topología.
a. Verdadero
b. Falso
9. ¿Qué comando BGP anuncia una ruta resumen para evitar el procesamiento de link-
flap por parte de los routers BGP descendentes?
a. aggregate-address network subnet-mask as-set
b. aggregate-address network subnet-mask summary-only
c. resumen-dirección red máscara-subred
d. summary-address network mask subnet-mask
10. Verdadero o falso: La familia de direcciones IPv6 debe ser inicializada para
establecer una sesión BGP con un peer que utilice direccionamiento IPv6.
a. Verdadero
b. Falso

Temas básicos
Fundamentos de BGP
Desde la perspectiva de BGP, un sistema autónomo (AS) es una colección de routers bajo
el control de una única organización, que utiliza uno o más IGPs y métricas comunes para
enrutar paquetes dentro del AS. Si se usan múltiples IGPs o métricas dentro de un AS, el
AS debe aparecer consis- tente a los ASs externos en la política de enrutamiento. No se
requiere un IGP dentro de un AS; un AS podría utilizar BGP como único protocolo de
enrutamiento.

Números de sistema autónomo


Una organización que necesite conectarse a Internet debe obtener un número de sistema
autónomo (ASN). Los ASN eran originalmente de 2 bytes (rango de 16 bits), lo que
permitía obtener 65.535 ASN. Debido al agotamiento, el RFC 4893 amplió el campo ASN
para dar cabida a 4 bytes (rango de 32 bits). Esto permite que haya 4.294.967.295 ASN
únicos, lo que supone un gran aumento con respecto a los 65.535 ASN originales.
Hay dos bloques de ASN privados disponibles para que cualquier organización los utilice,
siempre y cuando nunca se intercambien públicamente en Internet. Los ASN 64.512-65.535
son ASN privados en el rango de ASN de 16 bits, y los 4.200.000.000-4.294.967.294 son
ASN privados en el rango ampliado de 32 bits.
La Autoridad de Asignación de Números de Internet (IANA) es responsable de asignar
todos los ASN públicos para garantizar que sean únicos a nivel mundial. IANA requiere
los siguientes elementos cuando se solicita un ASN público:

■ Prueba de un rango de red asignado públicamente

■ Prueba de que la conectividad a Internet se proporciona a través de múltiples conexiones

■ Necesidad de una política de enrutamiento única por parte de los proveedores


En caso de que una organización no pueda proporcionar esta información, deberá
utilizar el ASN proporcionado por su proveedor de servicios.

NOTA Es imprescindible utilizar únicamente el ASN asignado por IANA, el ASN asignado por
su proveedor de servicios o un ASN privado. Utilizar el ASN de otra organización sin permiso
podría provocar pérdidas de tráfico y causar estragos en Internet.

Atributos de la ruta
BGP utiliza atributos de ruta (PAs) asociados a cada ruta de red. Los PAs proporcionan a
BGP granularidad y control de las políticas de enrutamiento dentro de BGP. Los PAs
del prefijo BGP se clasifican de la siguiente manera:

■ Conocida como obligatoria

■ Conocida discrecionalidad

■ Transitivo opcional

■ Opcional no transitivo

Según el RFC 4271, los atributos conocidos deben ser reconocidos por todas las
implementaciones de BGP. Los atributos obligatorios bien conocidos deben incluirse
en cada anuncio de prefijo;
Los atributos discrecionales conocidos pueden incluirse o no con un anuncio de prefijo.
Los atributos opcionales no tienen que ser reconocidos por todas las implementaciones
de BGP. Los atributos opcionales pueden establecerse para que sean transitivos y
permanezcan con el anuncio de ruta de AS a AS. Otros AP son no transitivos y no
pueden ser compartidos de AS a AS. En BGP, la Información de Alcanzabilidad de la
Capa de Red (NLRI) es una actualización de enrutamiento que consiste en el prefijo de
red, la longitud del prefijo y cualquier PA de BGP para la ruta específica.

Prevención del bucle


BGP es un protocolo de enrutamiento de vector de ruta y no contiene una topología
completa de la red, como hacen los protocolos de enrutamiento de estado de enlace.
BGP se comporta como los protocolos de vector distancia, asegurando que una ruta
está libre de bucles.
El atributo AS_Path de BGP es un atributo obligatorio bien conocido e incluye una lista
completa de todos los ASN que el anuncio de prefijo ha atravesado desde su AS de origen.
AS_Path se utiliza como un mecanismo de prevención de bucles en BGP. Si un router BGP
recibe un anuncio de prefijo con su AS listado en el atributo AS_Path, descarta el prefijo
porque el router piensa que el anuncio forma un bucle.
La figura 11-1 muestra el mecanismo de prevención de bucles:

■ El AS 100 anuncia el prefijo 172.16.1.0/24 al AS 200.

■ El AS 200 anuncia el prefijo al AS 400, que a su vez lo anuncia al AS 300.

■ El AS 300 anuncia el prefijo al AS 100 con un AS_Path de 300 400 200 100. El AS 100
11
se ve a sí mismo en la variable AS_Path y descarta el prefijo.
AS 200
AS AS 200 100
100

172.16.1.0/24
AS 400
AS 100

AS 400 200
COMO 300 400 100
200 100 AS 300

Figura 11-1 Prevención de bucles de vectores de ruta

Dirección de las familias


Originalmente, BGP estaba pensado para el enrutamiento de prefijos IPv4 entre
organizaciones, pero el RFC 2858 añadió la capacidad de BGP multiprotocolo (MP-BGP)
añadiendo una extensión denominada identificador de familia de direcciones (AFI). Una
familia de direcciones se correlaciona con un protocolo de red específico, como IPv4 o IPv6,
y se proporciona granularidad adicional a través de un identificador de familia de direcciones
(SAFI) posterior, como unicast o multicast. MBGP logra esta separación utilizando los
atributos de ruta (PA) de BGP MP_REACH_NLRI y MP_UNREACH_NLRI. Estos
atributos se llevan dentro de los mensajes de actualización de BGP y se utilizan para llevar
la información de alcanzabilidad de la red para diferentes familias de direcciones.

NOTA Algunos ingenieros de redes se refieren a BGP multiprotocolo como MP-BGP, y otros
ingenieros de redes utilizan el término MBGP. Ambos términos se refieren a lo mismo.

Cada familia de direcciones mantiene una base de datos y una configuración separada para
cada protocolo (familia de direcciones + subfamilia de direcciones) en BGP. Esto permite que una
política de enrutamiento en una familia de direcciones sea diferente de una política de
enrutamiento en una familia de direcciones diferente, aunque el router utilice la misma
sesión BGP con el otro router. BGP incluye un AFI y un SAFI con cada anuncio de ruta para
diferenciar entre las bases de datos AFI y SAFI.

Comunicación entre routers


BGP no utiliza paquetes hello para descubrir vecinos, como hacen los protocolos IGP, y no
puede descubrir vecinos dinámicamente. BGP fue diseñado como un protocolo de
enrutamiento interautonómico, lo que implica que las adyacencias de los vecinos no deben
cambiar con frecuencia y están coordinadas. Los vecinos de BGP se definen por dirección
IP.
BGP utiliza el puerto TCP 179 para comunicarse con otros routers. TCP permite
manejar la fragmentación, la secuenciación y la fiabilidad (reconocimiento y
retransmisión) de
paquetes de comunicación. Las implementaciones más recientes de BGP establecen el bit
de no fragmentación (DF) para evitar la fragmentación y se basan en el descubrimiento de
la MTU de la ruta.
Los IGP siguen la topología física porque las sesiones se forman con hellos que no
pueden cruzar los límites de la red (es decir, sólo un salto). BGP utiliza TCP, que es capaz de

Respuestas al cuestionario "¿Ya lo sé? ":


1 A, C 2 A 3 B 4 B 5 B 6 B 7 C 8 B 9 B 10 A
cruzando los límites de la red (es decir, con capacidad para varios saltos). Mientras que
BGP puede formar adyacencias de vecinos que están conectados directamente, también
puede formar adyacencias que están a múltiples saltos de distancia.
Una sesión BGP se refiere a la adyacencia establecida entre dos routers BGP. Las
sesiones multisalto requieren que el router utilice una ruta subyacente instalada en la
RIB (estática o de cualquier protocolo de enrutamiento) para establecer la sesión TCP
con el punto final remoto.
En la Figura 11-2, R1 puede establecer una sesión BGP directa con R2. Además, R2
puede establecer una sesión BGP con R4, aunque pase por R3. R1 y R2 utilizan un
ruta directamente conectada para localizarse entre sí. R2 utiliza una ruta estática para
alcanzar la red 10.34.1.0/24, y R4 tiene una ruta estática para alcanzar la red 10.23.1.0/24. R3
no sabe que R2 y R4 han establecido una sesión BGP aunque los paquetes fluyen a través
de R3.

Peering BGP Peering BGP

R1 R2 R3 R4
10.12.1.0/2410.23.1.0/2410.34.1.0/24

Figura 11-2 Sesiones BGP de uno y varios bucles


NOTA Los vecinos BGP conectados a la misma red utilizan la tabla ARP para localizar la
dirección IP del peer. Las sesiones BGP multisalto requieren información de la tabla de
enrutamiento para encontrar la dirección IP del peer. Es común tener una ruta estática o un
IGP corriendo entre vecinos iBGP para proveer la información de la ruta topológica para
establecer la sesión BGP TCP.
Una ruta por defecto no es suficiente para establecer una sesión BGP multisalto.

BGP puede considerarse como un protocolo de enrutamiento en el plano de control o


como una aplicación, ya que permite el intercambio de rutas con un compañero que está a
varios saltos de distancia. Los routers BGP no tienen que estar en el plano de datos (ruta)
para intercambiar prefijos, pero todos los routers en la ruta de datos necesitan conocer
todas las rutas que serán reenviadas a través de ellos.

Tipos de sesión BGP


Las sesiones BGP se clasifican en dos tipos:

■ BGP interno (iBGP): Sesiones establecidas con un router iBGP que están en el
mismo AS o que participan en la misma confederación BGP. A los prefijos iBGP se
les asigna una distancia administrativa (AD) de 200 al instalarse en la RIB del
router.

■ BGP externo (eBGP): Sesiones establecidas con un router BGP que están en un AS
diferente. A los prefijos eBGP se les asigna un AD de 20 al instalarse en la RIB del
router.

Las siguientes secciones revisan estos dos tipos de sesiones BGP.


11
iBGP
La necesidad de BGP dentro de un AS suele darse cuando se requieren múltiples políticas de
enrutamiento o cuando se proporciona conectividad de tránsito entre sistemas autónomos.
En la Figura 11-3, el AS 65200 proporciona conectividad de tránsito al AS 65100 y al AS
65300. El AS 65100 se conecta en R2 y el AS 65300 se conecta en R4.
Empresa 1Empresa 2Empresa 3

AS 65100 AS 65200 AS 65300

R1 R2 OSPF R3 EIGRP R4 R5

Figura 11-3 AS 65200 que proporciona conectividad de tránsito


R2 podría formar una sesión iBGP directamente con R4, pero R3 no sabría hacia dónde
enrutar el tráfico del AS 65100 o del AS 65300 cuando el tráfico de cualquiera de los dos
AS llegara a R3, como se muestra en la Figura 11-4, porque R3 no tendría la información
de reenvío de ruta apropiada para el tráfico de destino.

AS 65200
Peering IBGP

10.1.12.0/24 10.23.1.0/24 10.34.1.0/24 10.45.1.0/24


Gi0/0 R2 Gi0/1 Gi0/0 R3 Gi0/1 Gi0/0 R4Gi0/1

Red Próxim Red Próxim Red Próxim


o salto o salto o salto
C Gi0/0 C Gi0/0 B 10.23.1
10.12.1.0/24 10.23.1.0/24 10.12.1.0/24 .2
B 10.34.1 C Gi0/1
10.45.1.0/24 .4 10.45.1.0/24
C Gi0/1 S 10.34.1
Figura 11-4 Comportamiento de los anuncios de prefijos de iBGP
Se podría suponer que redistribuyendo la tabla BGP en un IGP se supera el problema, pero esto
no es una solución viable por varias razones:

■ Escalabilidad: En el momento de escribir este artículo, Internet tiene más de


780.000 prefijos de red IPv4 y su tamaño sigue aumentando. Los IGP no pueden
escalar a ese nivel de rutas.

■ Enrutamiento personalizado: Los protocolos de estado de enlace y los protocolos de


enrutamiento de vector distancia utilizan la métrica como método principal para la
selección de rutas. Los protocolos IGP siempre utilizan este patrón de enrutamiento
para la selección de rutas. BGP utiliza varios pasos para identificar la mejor ruta y
permite que los atributos de ruta de BGP manipulen la ruta para un prefijo
específico (NLRI). El
El camino podría ser más largo, y eso normalmente se consideraría subóptimo
desde la perspectiva de un IGP.

■ Atributos de ruta: Todos los atributos de ruta de BGP no se pueden mantener


dentro de los protocolos IGP. Sólo BGP es capaz de mantener el atributo de ruta
mientras el prefijo se anuncia desde un borde del AS al otro borde.

El establecimiento de sesiones iBGP entre todos los mismos routers (R2, R3 y R4) en
una malla completa permite el reenvío adecuado entre sistemas autónomos.
NOTA Los proveedores de servicios proporcionan conectividad de tránsito. Las
organizaciones empresariales son consumidores y no deberían proporcionar conectividad de
tránsito entre sistemas autónomos a través de Internet.

eBGP
Los peerings eBGP son el componente principal de BGP en Internet. eBGP implica el
intercambio de prefijos de red entre sistemas autónomos. Los siguientes comportamientos
son diferentes en las sesiones eBGP que en las sesiones iBGP:

■ El tiempo de vida (TTL) de los paquetes eBGP se establece por defecto en 1. Los
paquetes eBGP se caen en tránsito si se intenta una sesión BGP multisalto. (El TTL de
los paquetes iBGP se establece en 255, lo que permite realizar sesiones multisalto).

■ El router anunciante modifica la dirección de siguiente salto BGP a la dirección IP


que origina la conexión BGP.

■ El router anunciante añade su ASN a la variable AS_Path existente.

■ El router receptor verifica que la variable AS_Path no contiene un ASN que


coincida con los routers locales. BGP descarta el NLRI si falla la comprobación
de prevención de bucles AS_Path.

Las configuraciones para las sesiones eBGP e iBGP son fundamentalmente las mismas,
excepto que el ASN en la declaración remote-as es diferente del ASN definido en el
proceso BGP.
La Figura 11-5 muestra las sesiones eBGP e iBGP que serían necesarias entre los routers
para permitir la conectividad entre el AS 65100 y el AS 65300. Observe que el AS 65200 R2
establece una sesión iBGP con el R4 para superar el comportamiento de prevención de
bucles de las rutas aprendidas en iBGP.

Empresa 1Empresa 2Empresa 3

AS 65100 iBGP AS 65200iBGP AS 65300

R1 eBGP R2 R3 R4 eBGP R5
iBGP

Figura 11-5 Sesiones eBGP e iBGP


Mensajes BGP
La comunicación BGP utiliza cuatro tipos de mensajes, como se muestra en la Tabla 11-2.

Tabla 11-2 Tipos de paquetes BGP


Tipo Nombre Resumen funcional
1 ABIERTO Configura y establece la adyacencia BGP
2 ACTUALIZACIÓN Anuncia, actualiza o retira rutas
11
3 NOTIFICACIÓN Indica una condición de error a un vecino
BGP
4 KEEPALIVE Asegura que los vecinos de BGP siguen
vivos
■ OPEN: Un mensaje OPEN se utiliza para establecer una adyacencia BGP. Ambas
partes negocian las capacidades de la sesión antes de establecer el peering BGP. El
mensaje OPEN contiene el número de versión de BGP, el ASN del router de origen,
el tiempo de espera, el identificador BGP y otros parámetros opcionales que
establecen las capacidades de la sesión.

■ Tiempo de espera: El atributo hold time establece el temporizador de retención, en


segundos, para cada vecino BGP. Al recibir una actualización o KEEPALIVE, el
temporizador de retención se restablece al valor inicial. Si el temporizador de
retención llega a cero, la sesión BGP se interrumpe, las rutas de ese vecino se
eliminan, y se envía un mensaje de retirada de ruta de actualización apropiado a
otros vecinos BGP para los prefijos afectados. El tiempo de retención es un
mecanismo de control para que los vecinos BGP se aseguren de que un vecino está
sano y vivo.

Cuando se establece una sesión BGP, los routers utilizan el valor de tiempo de
retención más pequeño contenido en los mensajes OPEN de los dos routers. El
valor del tiempo de retención debe ser de al menos 3 segundos, o se establece en
0 para desactivar los mensajes keepalive. Para los routers Cisco, el tiempo de
retención por defecto es de 180 segundos.

■ Identificador BGP: El identificador del router BGP (RID) es un número único de


32 bits que identifica al router BGP en los prefijos anunciados. El RID puede
utilizarse como mecanismo de prevención de bucles para los enrutadores
anunciados dentro de un sistema autónomo. El RID puede establecerse manual o
dinámicamente para BGP. Para que los routers se conviertan en vecinos se debe
establecer un valor distinto de cero.

■ KEEPALIVE: BGP no se basa en el estado de la conexión TCP para asegurar que los
vecinos siguen vivos. Los mensajes KEEPALIVE se intercambian cada un tercio del
tiempo de retención acordado entre los dos routers BGP. Los dispositivos Cisco
tienen un tiempo de retención por defecto de 180 segundos, por lo que el intervalo de
keepalive por defecto es de 60 segundos. Si el tiempo de retención se establece en 0,
entonces no se envían mensajes keepalive entre los vecinos BGP.

■ UPDATE: Un mensaje UPDATE anuncia cualquier ruta factible, retira rutas


previamente anunciadas, o puede hacer ambas cosas. Un mensaje UPDATE incluye
la información de alcanzabilidad de la capa de red (NLRI), como el prefijo y los PAs
BGP asociados, cuando se anuncian prefijos. Los NLRI retirados incluyen sólo el
prefijo. Un mensaje UPDATE puede actuar como un keepalive para reducir el tráfico
innecesario.

■ NOTIFICACIÓN: Se envía un mensaje de NOTIFICACIÓN cuando se detecta un


error en la sesión BGP, como por ejemplo que el temporizador de retención haya
expirado, que las capacidades del vecino hayan cambiado o que se haya solicitado
un reinicio de la sesión BGP. Esto hace que la conexión BGP se cierre.

Estados de los vecinos de BGP


BGP forma una sesión TCP con los routers vecinos llamados peers. BGP utiliza la
máquina de estado finito (FSM) para mantener una tabla de todos los peers BGP y su
estado operativo. La sesión BGP puede reportar los siguientes estados:
■ Ocioso

■ Conectar

■ Activo

■ OpenSent
■ OpenConfirm

■ Establecido

La Figura 11-6 muestra el FSM de BGP y los estados, listados en el orden en que se
establece una sesión BGP.

R1R2

Ocio
so

Conectar

Abierto
enviado (en IP de origen (10.12.1.1) Remote-AS 100
espera de

Abierto
enviado IP de origen (10.12.1.2) Remote-AS 100

Confirmar
abierto

Keepalive

Establecido

Actualizacion
es
Mi tabla BGP Mi tabla BGP

Figura 11-6 Estados del vecino BGP con establecimiento de sesión


Ocioso
La fase de inactividad es la primera etapa del FSM de BGP. BGP detecta un evento de
inicio e intenta iniciar una conexión TCP con el peer BGP y también escucha una nueva
conexión de un router peer.
Si un error hace que BGP vuelva al estado Idle por segunda vez, el ConnectRetryTimer se
establece en 60 segundos y debe decrecer hasta cero antes de que la conexión pueda 11
iniciarse de nuevo. Si se producen más fallos al salir del estado Idle, el ConnectRetryTimer
se duplica con respecto a la vez anterior.
Conectar
En el estado Connect, BGP inicia la conexión TCP. Si el handshake TCP de tres vías se
completa, el proceso de la sesión BGP establecida reinicia el ConnectRetryTimer y envía el
mensaje Open al vecino; entonces cambia al estado OpenSent.
Si el ConnectRetryTimer se agota antes de que se complete esta etapa, se intenta una
nueva conexión TCP, el ConnectRetryTimer se reinicia y el estado pasa a Activo. Si se
recibe cualquier otra entrada, el estado se cambia a Idle.
Durante esta etapa, el vecino con la dirección IP más alta gestiona la conexión. El router que
inicia la solicitud utiliza un puerto de origen dinámico, pero el puerto de destino es siempre
179.
El ejemplo 11-1 muestra una sesión BGP establecida utilizando el comando show tcp brief
para mostrar las sesiones TCP activas entre un router. Observe que el puerto de origen
TCP es 179 y el puerto de destino es 59884 en el R1; los puertos son opuestos en el R2.
Ejemplo 11-1 Una sesión BGP establecida

R1# resumen tcp


show Dirección local Dirección (est
TCB 10.12.1.1.59884 extranjera ado)
F6F84 10.12.1.2.179 ESTAB
258
R2# resumen tcp
mostra
Dirección local Dirección (est
r
10.12.1.2.59884 extranjera ado
TCB
10.12.1.1.179 )
EF153
EST
B88
AB

Activo
En el estado Activo, BGP inicia un nuevo handshake TCP de tres vías. Si se establece una
conexión, se envía un mensaje Open, el temporizador de retención se establece en 4
minutos y el estado pasa a OpenSent. Si este intento de conexión TCP fracasa, el estado
vuelve al estado Connect, y el ConnectRetryTimer se reinicia.

OpenSent
En el estado OpenSent, se ha enviado un mensaje Open desde el router de origen y está
esperando un mensaje Open del otro router. Una vez que el router de origen recibe el
mensaje OPEN del otro router, ambos mensajes OPEN se comprueban en busca de
errores. Se examinan los siguientes elementos:

■ Las versiones de BGP deben coincidir.

■ La dirección IP de origen del mensaje OPEN debe coincidir con la dirección IP


configurada para el vecino.

■ El número de AS en el mensaje OPEN debe coincidir con el configurado para el vecino.

■ Los identificadores BGP (RID) deben ser únicos. Si un RID no existe, esta condición no se cumple.

■ Los parámetros de seguridad (como la contraseña y el TTL) deben configurarse adecuadamente.


Si los mensajes OPEN no tienen ningún error, se negocia el tiempo de retención
(utilizando el valor más bajo) y se envía un mensaje KEEPALIVE (suponiendo que el
valor no sea 0). El estado de la conexión pasa entonces a OpenConfirm. Si se encuentra
un error en el mensaje OPEN, se envía un mensaje NOTIFICATION y el estado vuelve a
ser Idle.
Si TCP recibe un mensaje de desconexión, BGP cierra la conexión, reinicia el
ConnectRetryTimer, y establece el estado a Activo. Cualquier otra entrada en este proceso hace
que el estado pase a Idle.

OpenConfirm
En el estado OpenConfirm, BGP espera un mensaje KEEPALIVE o NOTIFICATION. Al
recibir un mensaje KEEPALIVE de un vecino, el estado pasa a Establecido. Si el
temporizador de retención expira, se produce un evento de parada, o si se recibe un
mensaje NOTIFICATION, el estado pasa a Idle.

Establecido
En el estado Establecido, se establece la sesión BGP. Los vecinos de BGP intercambian
rutas mediante mensajes UPDATE. A medida que se reciben mensajes UPDATE y
KEEPALIVE, el temporizador de retención se reinicia. Si el temporizador de retención
expira, se detecta un error y BGP devuelve al vecino al estado Idle.

Configuración básica de BGP


Al configurar BGP, es mejor pensar en la configuración desde una perspectiva modular.
La configuración del router BGP requiere los siguientes componentes:

■ Parámetros de sesión BGP: Los parámetros de sesión BGP proporcionan ajustes que
implican el establecimiento de la comunicación con el vecino BGP remoto. La
configuración de la sesión incluye el ASN del peer BGP, la autenticación y los
temporizadores de mantenimiento de la vida.

■ Inicialización de la familia de direcciones: La familia de direcciones se inicializa


bajo el modo de configuración del router BGP. La publicidad de la red y el
resumen ocurren dentro de la familia de direcciones.

■ Activar la familia de direcciones en el peer BGP: Para que se inicie una sesión, se debe
activar una familia de direcciones para un vecino. La dirección IP del router se añade
a la tabla de vecinos, y BGP intenta establecer una sesión BGP o acepta una sesión
BGP iniciada desde el router peer

Los siguientes pasos muestran cómo configurar BGP:

Paso 1. Inicie el proceso de enrutamiento BGP con el comando global router bgp
como número.
Paso 2. (Opcional) Defina estáticamente el ID del enrutador BGP (RID). La lógica de
asignación dinámica del RID utiliza la dirección IP más alta de las interfaces
loopback activas. Si no hay una interfaz loopback activa, la dirección IP más
alta de cualquier interfaz activa se convierte en el RID cuando el proceso BGP
se inicializa.
Para asegurar que el RID no cambie, se asigna un RID estático (que suele
representar una dirección IPv4 que reside en el router, como una dirección
loopback). Se puede utilizar cualquier dirección IPv4, incluyendo direcciones
IP no configuradas en el router. Configurar estáticamente el RID de BGP es
una buena práctica y consiste en utilizar el comando bgp router-id router-id.
11
Cuando el ID del enrutador cambia, todas las sesiones BGP se reinician y necesitan ser
restablecidas.
Paso 3. Identifique la dirección IP y el número de sistema autónomo del vecino BGP con el
comando de configuración del router BGP neighbor ip-address remote-as as-
number. Es importante entender el flujo de tráfico de los paquetes BGP entre
peers.
La dirección IP de origen de los paquetes BGP sigue reflejando la dirección IP
de la interfaz de salida. Cuando se recibe un paquete BGP, el router correlaciona
la dirección IP de origen del paquete con la dirección IP configurada para ese
vecino. Si el origen del paquete BGP no coincide con una entrada en la tabla de
vecinos, el paquete no puede ser asociado a un vecino y es descartado.
NOTA IOS activa la familia de direcciones IPv4 por defecto. Esto puede simplificar la
configuración en un entorno IPv4 porque los pasos 4 y 5 son opcionales, pero puede causar
confusión cuando se trabaja con otras familias de direcciones. El comando de configuración
del enrutador BGP no bgp default ip4-unicast desactiva la activación automática del AFI IPv4 para
que los pasos 4 y 5 sean necesarios.

Paso 4. Inicialice la familia de direcciones con el comando de configuración del


enrutador BGP address-family afi safi. Los ejemplos de valores afi son IPv4 e
IPv6, y los ejemplos de valores safi son unicast y multicast.
Paso 5. Active la familia de direcciones para el vecino BGP con el comando de
configuración de la familia de direcciones BGP neighbor ip-address activate.

NOTA En los dispositivos IOS e IOS XE, el identificador de familia de direcciones posterior
(SAFI) por defecto para las familias de direcciones IPv4 e IPv6 es unicast y es opcional.

La Figura 11-7 muestra una topología para una configuración simple de BGP.

AS 65100 AS 65200

R1 10.12.1.0/24 R2
Loopback 0 Loopback 0
192.168.1.1 192.168.2.2
Figura 11-7 Topología BGP simple
El ejemplo 11-2 muestra cómo configurar el R1 y el R2 utilizando la sintaxis de la CLI del
modificador de IPv4 por defecto y opcional. R1 está configurado con la familia de
direcciones IPv4 por defecto activada, y R2 desactiva la familia de direcciones IPv4 por
defecto del IOS y la activa manualmente para el vecino específico 10.12.1.1.
Ejemplo 11-2 Configuración de BGP básico en IOS

R1 (Familia de direcciones IPv4 por defecto activada)


router bgp 65100
vecino 10.12.1.2 remote-as 65200

R2 (Familia de direcciones IPv4 por defecto deshabilitada)


router bgp 65200
no bgp default ipv4-unicast
vecino 10.12.1.1 remote-as 65100
!
address-family ipv4
neighbor 10.12.1.1
activate exit-address-
family

Verificación de las sesiones BGP


La sesión BGP se verifica con el comando show bgp afi safi summary. El ejemplo 11-3
muestra el resumen de BGP unicast IPv4. Observe que el RID de BGP y la versión de la
tabla son los primeros componentes mostrados. La columna Up/Down indica que la sesión
BGP está activa por más de 5 minutos.

NOTA Los comandos anteriores como show ip bgp summary salieron antes de MBGP y no
proporcionan una estructura para las capacidades multiprotocolo actuales dentro de BGP. El uso de la
sintaxis AFI y SAFI asegura la consistencia de los comandos, independientemente de la información
intercambiada por BGP. Esto se hará más evidente cuando los ingenieros trabajen con familias de
direcciones como IPv6, VPNv4 y VPNv6.

Ejemplo 11-3 Verificación del resumen de la sesión BGP IPv4

R1# show bgp ipv4 unicast summary


Identificador del enrutador BGP 192.168.2.2, número de
AS local 65200 La versión de la tabla BGP es 1, versión
de la tabla de enrutamiento principal 1

NeighborVAS MsgRcvd MsgSentTblVer InQ OutQ Up/Down State/PfxRcd 10.12.1. 24


6520089 100 00:05:23 0

La Tabla 11-3 explica los campos de salida que se muestran en una tabla BGP (como en el Ejemplo 11-3).

Tabla 11-3 Campos de resumen de BGP


Campo Descripción
Vecino Dirección IP del peer BGP
V Versión de BGP hablada por el peer BGP
AS Número de sistema autónomo del peer BGP
MsgRcvd Recuento de mensajes recibidos del peer BGP
MsgSent Recuento de mensajes enviados al peer BGP
TblVer Última versión de la base de datos BGP enviada al peer
InQ Número de mensajes en cola para ser procesados por el peer
OutQ Número de mensajes en cola para ser enviados al peer
Arriba/Abajo Duración de la sesión BGP establecida o el estado actual si la sesión
no está en estado establecido
Estado/PfxR Estado actual del peer BGP o el número de prefijos recibidos del peer 11
cd

El estado de la sesión de los vecinos BGP, los temporizadores y otra información esencial
de peering está disponible con el comando show bgp afi safi neighbors ip-address, como
se muestra en el Ejemplo 11-4.
Ejemplo 11-4 Salida de vecinos BGP IPv4

R2# show bgp ipv4 unicast neighbors 10.12.1.1


! Salida omitida por brevedad

! La primera sección proporciona la dirección IP del vecino, remote-as, indica si


! el vecino es "interno" o "externo", la versión BGP del vecino, RID,
El estado de la sesión y los temporizadores.

El vecino BGP es 10.12.1.1, AS65100 remoto, enlace


externo BGP versión 4, ID del router remoto
192.168.1.1
Estado de BGP = Establecido, en funcionamiento durante 00:01:04
Última lectura 00:00:10, última escritura 00:00:09, hold es 180, keepalive es 60
segundos Sesiones vecinas:
1 activo, no tiene capacidad de multisesión (desactivado)
! Esta segunda sección indica las capacidades del vecino BGP y
! familias de direcciones configuradas en el vecino.
Capacidades de los vecinos:
Actualización de la ruta: anunciada y recibida (nueva)
Capacidad ASN de cuatro octetos: anunciada y
recibida Familia de direcciones IPv4 Unicast:
anunciada y recibida Capacidad de actualización
mejorada: anunciada
Capacidad de multisesión:
Soporte de Stateful switchover habilitado: NO para
la sesión 1 Estadísticas de mensajes:
La
profundidad
InQ es 0 La
profundidad
OutQ es 0

! Esta sección proporciona una lista de los tipos de paquetes BGP que se han recibido
! o enviado al router vecino.
SentRcvd
Abre: 11
Notificaciones: 00
Actualizaciones: 00
Mantenimientos: 22
Ruta Refresh: 00
Total: 43
El tiempo mínimo por defecto entre ejecuciones de anuncios es de
0 segundos

! Esta sección proporciona la versión de la tabla BGP de la dirección IPv4 Unicast.


familia. La versión de la tabla no es una correlación 1 a 1 con las rutas ya que
múltiples
! el cambio de ruta puede ocurrir durante un cambio de revisión. Observe la actividad
del prefijo
! columnas en esta sección.

Para la familia de direcciones: IPv4


Unicast Sesión: 10.12.1.1
Tabla BGP versión 1, vecino versión 1/0
Tamaño de la cola de
salida : 0 Índice 1,
Bit de publicidad 0
SentRcvd
Actividad del prefijo :--------
Prefijos Actual: 00
Prefijos Total: 00
Retirada implícita: 00
Retirada explícita: 00
Utilizado como bestpath: n/a0
Utilizado como multirruta: n/a0

OutboundInbound
Política local denegada Prefijos :---------------
Total: 00
Número de NLRIs en la actualización enviada: máximo
0, mínimo 0

! Esta sección indica que existe una ruta válida en la RIB hacia el peer IP de BGP
! dirección, proporciona el número de veces que se ha establecido la conexión y
tiempo de caída, desde el último reinicio, la razón del reinicio, si path-mtu-
! el descubrimiento está habilitado, y los puertos utilizados para la sesión BGP.

El seguimiento de direcciones está activado, la RIB tiene una


ruta a 10.12.1.1 Conexiones establecidas 2; abandonadas 1
Último reinicio 00:01:40, debido a que el par cerró
la sesión Transporte(tcp) path-mtu-discovery está
activado
El estado de la conexión es ESTAB, estado de E/S: 1, bytes de
entrada no leídos: 0 TTL mínimo de entrada 0, TTL de salida 255
Host local: 10.12.1.2, Puerto local: 179
Host extranjero: 10.12.1.1, Puerto extranjero: 56824

Anuncio del prefijo


Las declaraciones de red BGP no habilitan BGP para una interfaz específica; en cambio,
identifican prefijos de red específicos que se instalarán en la tabla BGP, conocida como
tabla Loc-RIB.
Después de configurar una declaración de red BGP, el proceso BGP busca en la RIB global
para una coincidencia exacta del prefijo de red. El prefijo de red puede ser para una red
conectada, una red conectada secundaria o cualquier ruta de un protocolo de
enrutamiento. Después de verificar que la declaración de red coincide con un prefijo en la
RIB global, el prefijo se instala en la tabla Loc-RIB de BGP. Cuando el prefijo BGP se
instala en la tabla Loc-RIB, se establecen los siguientes PA de BGP, dependiendo del tipo
de prefijo de la RIB:

■ Red conectada: El atributo BGP de siguiente salto se establece en 0.0.0.0, el


atributo de origen BGP se establece en i (IGP) y el peso BGP se establece en 11
32.768.
■ Ruta estática o protocolo de enrutamiento: El atributo BGP de siguiente salto se
establece en la dirección IP de siguiente salto en la RIB, el atributo de origen BGP se
establece en i (IGP), el peso BGP se establece en 32.768 y el MED se establece en la
métrica IGP.
No todas las rutas de la tabla Loc-RIB se anuncian a un peer BGP. Todas las rutas de la
tabla Loc-RIB utilizan el siguiente proceso para anunciarse a los peers de BGP.

Paso 1. Pasar una comprobación de validez. Comprueba que el NRLI es válido y


que la dirección del siguiente salto se puede resolver en la RIB global. Si el

red
Declaración de la
te
Consul
RIB
(Base de datos BGP)
Loc-RIB
validez
de
obación
Compr

Adj-RIB-Out
salida
Políticas de rutas de
pares
los
hacia
Rutas

NRLI falla, el NLRI permanece pero no se procesa más.


Paso 2. Procesar las políticas de ruta de salida de los vecinos. Tras el procesamiento,
si una ruta no fue denegada por las políticas de salida, la ruta se mantiene en
la tabla Adj-RIB-Out para su posterior consulta.
Paso 3. Anuncie el NLRI a los peers BGP. Si el PA BGP de siguiente salto del NLRI es
0.0.0.0, entonces la dirección de siguiente salto se cambia a la dirección IP de la
sesión BGP.
La Figura 11-8 ilustra el concepto de instalación del prefijo de red desde los anuncios de
red BGP localizados a la tabla BGP.

Figura 11-8 Procesamiento de la base de datos BGP de anuncios de rutas locales


NOTA BGP sólo anuncia la mejor ruta a otros peers BGP, independientemente del número de
rutas (NLRIs) en la tabla BGP Loc-RIB.

La declaración de red reside bajo la familia de direcciones apropiada dentro de la


configuración del router BGP. El comando network network mask subnet-mask [route-
map route-map- name] se utiliza para anunciar redes IPv4. El mapa de ruta opcional
proporciona un método
de establecer PAs BGP específicos cuando el prefijo se instala en la tabla Loc-RIB. Los
mapas de ruta se tratan con más detalle en el Capítulo 12.
La Figura 11-7 ilustra al R1 y al R2 conectados a través de la red 10.12.1.0/24. El ejemplo 11-
5 muestra la configuración en la que ambos routers anunciarán las interfaces Loopback 0
(192.168.1.1/32 y 192.168.2.2/32, respectivamente) y la red 10.12.1.0/24 en BGP. Observe que
R1 utiliza la familia de direcciones IPv4 por defecto, y R2 especifica explícitamente la
familia de direcciones IPv4.
Ejemplo 11-5 Configuración de la publicidad de red BGP

R1
router bgp 65100
bgp log-neighbor-changes
no bgp default ipv4-unicast
vecino 10.12.1.2 remote-as 100
red 10.12.1.0 máscara 255.255.255.0
red 192.168.1.1 máscara 255.255.255.255

R2
router bgp 65200
bgp log-neighbor-changes

no bgp default ipv4-unicast


neighbor 10.12.1.1 remote-as 65100
!
address-family ipv4
red 10.12.1.0 máscara 255.255.255.0
red 192.168.2.2 máscara 255.255.255.255

vecino 10.12.1.1 activar


exit-address-family

Recepción y visualización de rutas


BGP utiliza tres tablas para mantener el prefijo de red y los atributos de ruta (PAs) de una ruta:

■ Adj-RIB-In: Contiene los NLRI en forma original (es decir, desde antes de que se
procesen las políticas de ruta de entrada). Para ahorrar memoria, la tabla se purga
después de procesar todas las políticas de ruta.

■ Loc-RIB: Contiene todos los NLRI originados localmente o recibidos de otros


peers BGP. Después de que los NLRIs pasen la comprobación de validez y
alcanzabilidad del siguiente salto, el algoritmo de mejor ruta de BGP selecciona el
mejor NLRI para un prefijo específico. La tabla Loc-RIB es la tabla utilizada para
presentar las rutas a la tabla de enrutamiento IP.

■ Adj-RIB-Out: Contiene los NLRI después de que se hayan procesado las políticas de ruta de salida.

No todos los prefijos de la tabla Loc-RIB se anuncian a un peer BGP o se instalan en la RIB
global cuando se reciben de un peer BGP. BGP realiza los siguientes pasos de
procesamiento de rutas:
Paso 1. Almacenar la ruta en la tabla Adj-RIB-In en el estado original y aplicar la
política de rutas de entrada basada en el vecino en el que se recibió la ruta.
Paso 2. Actualice la Loc-RIB con la última entrada. La tabla Adj-RIB-In se borra para
ahorrar memoria.
Paso 3. Pasa una comprobación de validez para verificar que la ruta es válida y que la
dirección del siguiente salto se puede resolver en la RIB global. Si la ruta falla,
la ruta permanece en la tabla Loc-RIB pero no se sigue procesando.
Paso 4. Identificar la mejor ruta BGP y pasar sólo la mejor ruta y sus atributos al
paso 5. El proceso de selección de la mejor ruta BGP se trata en el Capítulo
12.
Paso 5. Instale la ruta de mejor recorrido en la RIB global, procese la política de
rutas de salida, almacene las rutas no descartadas en la tabla Adj-RIB-Out y 11
anúnciela a los peers BGP.
La Figura 11-9 muestra la lógica completa de procesamiento de rutas BGP. Incluye la
recepción de una ruta de un peer BGP y el algoritmo de mejor ruta BGP.
Declaración de la Políticas de rutas de Rutas
red entrada Adj-RIB-In
desde los
pares

RIB Loc-RIB
Consul (Base de datos BGP)
te

Comprobación del Adj-RIB-Out Rutas


siguiente paso y de la hacia
validez los
pares

Instalar rutas Identificar la Políticas de rutas de


en el RIB mejor ruta salida
global BGP
Figura 11-9 Procesamiento de la base de datos BGP
El comando show bgp afi safi muestra el contenido de la base de datos BGP (Loc-RIB) en el
router. Cada entrada en la tabla Loc-RIB de BGP contiene al menos una ruta pero puede
contener múltiples rutas para el mismo prefijo de red. El ejemplo 11-6 muestra la tabla BGP
en R1, que contiene rutas recibidas y rutas generadas localmente.
Ejemplo 11-6 Visualización de la tabla BGP

R1# show bgp ipv4 unicast


La versión de la tabla BGP es 4, el ID del router local es 192.168.1.1
Códigos de estado: s suprimido, d amortiguado, h historial, * válido, > mejor, i -
interno,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x mejor-externo, a ruta-adicional, c RIB-comprimido,
Códigos de origen: i - IGP, e - EGP, ? - incompleto
Códigos de validación RPKI: V válido, I no válido, N no encontrado

RedSiguiente HopMétrico LocPrf Peso Ruta


*10 .12.1.0/2410 .12.1. 200 65200 i
*> 0.0 .0.0032768 i
*> 1 9 2 .168.1.1/320.0 .0.0032768 i
*> 1 9 2 .168.2.2/3210. 12.1.200 65200 i

R2# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*10 .12.1.0/2410 .12.1. 100 65100 i
*> 0.0 .0.0032768 i
*> 1 9 2 .168.1.1/3210. 12.1.100 65100 i
*> 1 9 2 .168.2.2/320.0. 0.0032768 i

La Tabla 11-4 explica los campos de salida cuando se muestra la tabla BGP.
Tabla 11-4 Campos de la tabla BGP
Campo Descripción
Red Una lista de los prefijos de red instalados en BGP. Si existen varios
NLRI para el mismo prefijo, sólo se identifica el primer prefijo y los
demás están en blanco.
Los NLRI válidos se indican con un *.
El NLRI seleccionado como la mejor ruta se indica con un corchete
angular (>).
Próximo salto Un atributo obligatorio bien conocido de la ruta BGP que define la
dirección IP del siguiente salto para ese NLRI específico.
Métrica Discriminador de salida múltiple (MED): Un atributo opcional de
ruta BGP no transitiva utilizado en BGP para el NLRI específico.
LocPrf Preferencia local: Un atributo discrecional bien conocido de la ruta
BGP utilizado en el algoritmo de mejor ruta BGP para el NLRI
específico.
Peso Un atributo localmente significativo definido por Cisco y utilizado
en el algoritmo de mejor ruta de BGP para el NLRI específico.
Trayectoria y AS_Path: Un atributo de ruta BGP obligatorio bien conocido que se
origen utiliza para la prevención de bucles y en el algoritmo de mejor
ruta BGP para el NLRI específico.
Origen: Un atributo obligatorio bien conocido de la ruta BGP que se
utiliza en el algoritmo de mejor ruta de BGP. Un valor de i representa
un IGP, e indica EGP, y ? indica una ruta que fue redistribuida en
BGP.

El comando show bgp afi safi network muestra todas las rutas para una ruta específica y
los atributos de ruta BGP para esa ruta. El ejemplo 11-7 muestra las rutas para la red
10.12.1.0/24. La salida incluye el número de rutas y qué ruta es la mejor.
Ejemplo 11-7 Visualización de rutas BGP explícitas y atributos de ruta

R1# show bgp ipv4 unicast 10.12.1.0


Entrada de la tabla de enrutamiento BGP para
10.12.1.0/24, versión 2 Rutas: (2 disponibles, mejor
#2, tabla por defecto)
Anunciado a los grupos de
actualización: 2
Refrescar la época 1
65200
10.12.1.2 desde 10.12.1.2 (192.168.2.2)
Origen IGP, métrica 0, localpref 100, válido,
pathid rx externo: 0, pathid tx: 0
Refrescar la época 1 11
Local
0.0.0.0 desde 0.0.0.0 (192.168.1.1)
Origen IGP, métrica 0, localpref 100, peso 32768, válido, originado, local,
mejor pathid rx: 0, pathid tx: 0x0

NOTA El comando show bgp afi safi detail muestra toda la tabla BGP con todos los atributos de la
ruta, como los que se muestran en el Ejemplo 11-7.
La tabla Adj-RIB-Out es una tabla única que se mantiene para cada peer BGP. Permite a un
ingeniero de redes ver las rutas anunciadas a un enrutador específico. El comando show bgp
afi safi neighbor ip-address advertised routes muestra el contenido de la tabla Adj-RIB-Out
de un vecino.
El ejemplo 11-8 muestra las entradas Adj-RIB-Out específicas de cada vecino. Observe que la
dirección del siguiente salto refleja el enrutador local y se cambiará a medida que la ruta se
anuncie al peer.
Ejemplo 11-8 Vista específica del vecino de la tabla Adj-RIB-Out

R1# show bgp ipv4 unicast neighbors 10.12.1.2 advertised-routes


! Salida omitida por brevedad
RedSiguiente HopMétrico LocPrf Peso Ruta
*> 10.12.1.0/240.0 .0.0032768 i
*> 192 .168.1.1/320.0 .0.0032768 i

Número total de prefijos 2

R2# show bgp ipv4 unicast neighbors 10.12.1.1 advertised-routes


! Salida omitida por brevedad
RedSiguiente HopMétrico LocPrf Peso Ruta
*> 10.12.1.0/240.0 .0.0032768 i
*> 192 .168.2.2/320.0. 0.0032768 i

Número total de prefijos 2

El comando show bgp ipv4 unicast summary también puede utilizarse para verificar el
intercambio de NLRIs entre nodos, como se muestra en el Ejemplo 11-9.
Ejemplo 11-9 Resumen de BGP con prefijos

R1# show bgp ipv4 unicast summary


! Salida omitida por brevedad
NeighborVAS MsgRcvd MsgSentTblVer InQ OutQ Up/Down State/ PfxRcd
10.12.1. 24652001110900 00:04:56 2

Las rutas BGP en la tabla global de enrutamiento IP (RIB) se muestran con el comando
show ip route bgp. El ejemplo 11-10 muestra estos comandos en la topología de ejemplo.
Los prefijos son de una sesión eBGP y tienen un AD de 20, y no hay métrica.
Ejemplo 11-10 Visualización de rutas BGP en una tabla de enrutamiento IP

R1# show ip route bgp | begin Gateway


La pasarela de último recurso no está configurada

192.168.2.0/32 está subredado, 1 subred


B192 .168.2.2 [20/0] vía 10.12.1.2, 00:06:12
Anuncios de rutas BGP de fuentes indirectas
Como se dijo anteriormente, BGP debe ser considerado como una aplicación de
enrutamiento ya que la sesión BGP y el anuncio de rutas son dos componentes separados.
La Figura 11-10 muestra una topología donde R1 instala múltiples rutas aprendidas de
rutas estáticas, EIGRP y OSPF. R1 puede anunciar estas rutas a R2.

Loopback 0
192.168.3.3R3

AS 65100 EI
10.13.1.0
/24G
RP
AS 65200
Loopback 0
192.168.4.4 R410.14.1.0/24 R110.12.1.0/24 R2

10.15.1.0
/24
O
S
Loopback 0 P
192.168.5.5 R5 F

Figura 11-10 Múltiples fuentes de rutas BGP


El ejemplo 11-11 muestra la tabla de enrutamiento de R1. Observe que el loopback de R3
fue aprendido a través de EIGRP, el loopback de R4 es alcanzado usando una ruta estática, y
el loopback de R5 es aprendido desde OSPF.
Ejemplo 11-11 Tabla de enrutamiento de R1 con Loopbacks para R3, R4 y R5

R1# show ip route


! Salida omitida por brevedad
Códigos: L - local, C - conectado, S - estático, R - RIP, M - móvil, B - BGP
D - EIGRP, EX - EIGRP externo, O - OSPF, IA - OSPF interárea
..
La pasarela de último recurso no está configurada

10.0.0.0/8 tiene una subred variable, 8 subredes, 2 máscaras


C 10.12.1.0/24 está directamente conectada,
GigabitEthernet0/0 C 10.13.1.0/24 está directamente
conectada, GigabitEthernet0/1 C 10.14.1.0/24 está
directamente conectada, GigabitEthernet0/2 C 10.15.1.0/24
está directamente conectada, GigabitEthernet0/3 C 192.168.1.1
está directamente conectada, Loopback0
B 192.168.2.2 [20/0] vía 10.12.1.2, 00:01:17
D192 .168.3.3 [90/3584] vía 10.13.1.3, 00:02:10, GigabitEthernet0/1
S192 .168.4.4 [1/0] vía 10.14.1.4
O192 .168.5.5 [110/11] vía 10.15.1.5, 00:00:08, GigabitEthernet0/3
11
El ejemplo 11-12 muestra la instalación del loopback de R3 y R4 utilizando una sentencia
de red. Especificar cada prefijo de red que debe ser anunciado puede parecer tedioso. El
loopback de R5 se aprendió redistribuyendo OSPF directamente en BGP.
Ejemplo 11-12 Configuración de rutas publicitarias para rutas no conectadas

R1
router bgp 65100
bgp log-neighbor-changes
red 10.12.1.0 máscara 255.255.255.0
red 192.168.1.1 máscara 255.255.255.255
red 192.168.3.3 máscara 255.255.255.255
red 192.168.4.4 máscara 255.255.255.255
redistribuir ospf 1
vecino 10.12.1.2 remote-as 65200

NOTA La redistribución de rutas aprendidas de un IGP a BGP es completamente segura; sin


embargo, la redistribución de rutas aprendidas de BGP debe hacerse con precaución. BGP
está diseñado para una gran escala y puede manejar una tabla de enrutamiento del tamaño
de Internet (780.000+ prefijos), mientras que los IGP podrían tener problemas de estabilidad
con menos de 20.000 rutas.

El ejemplo 11-13 muestra las tablas de enrutamiento BGP en R1 y R2. Observe que en R1, el
siguiente salto coincide con el siguiente salto aprendido de la RIB, el AS_Path está en
blanco, y los códigos de origen son IGP (para las rutas aprendidas de la declaración de
red) o incompleto (redistribuido). La métrica se traslada desde los protocolos de
enrutamiento IGP de R3 y R5 y se refleja como MED. R2 aprende las rutas estrictamente de
eBGP y sólo ve el MED y los códigos de origen.
Ejemplo 11-13 Tabla BGP para rutas de múltiples fuentes

R1# show bgp ipv4 unicast


La versión de la tabla BGP es 9, el ID del router local es 192.168.1.1
Códigos de estado: s suprimido, d amortiguado, h historial, * válido, >
mejor, i - interno, r RIB-fallo, S Stale, m multitrayecto, b
trayecto de respaldo, f RT-Filtro, x mejor-externo, a trayecto
adicional, c RIB-comprimido,
Códigos de origen: i - IGP, e - EGP, ? - incompleto
Códigos de validación RPKI: V válido, I no válido, N no encontrado

RedSiguiente HopMétrico LocPrf Peso Ruta


*> 10. 12.1.0/240.0 .0.0032768 i
*10 .12.1. 200 65200 i
*> 10. 15.1.0/240.0. 0.0032768 ?
*> 1 9 2 .168.1.1/320.0 .0.0032768 i
*> 1 9 2 .168.2.2/3210. 12.1.200 65200 i
! La siguiente ruta proviene de EIGRP y utiliza una declaración de red
*> 1 9 2 .168.3.3/3210. 13.1.3358432768 i
! La siguiente ruta proviene de una ruta estática y utiliza una declaración de red
*> 1 9 2 .168.4.4/3210. 14.1.4032768 i
! La siguiente ruta fue redistribuida desde la declaración OSPF
*> 1 9 2 .168.5.5/3210. 15.1.51132768 ?
R2# show bgp ipv4 unicast | begin Red
RedSiguiente HopMétrico LocPrf Peso Ruta
*10 .12.1.0/2410 .12.1. 100 65100 i
*> 0.0 .0.0032768 i
*> 10. 15.1.0/2410. 12.1.100 65100 ?
*> 1 9 2 .168.1.1/3210. 12.1.100 65100 i
*> 1 9 2 .168.2.2/320.0. 0.0032768 i
*> 1 9 2 .168.3.3/3210. 12.1.1 35840 65100
i
*> 1 9 2 .168.4.4/3210. 12.1.100 65100 i
*> 1 9 2 .168.5.5/3210. 12.1.1 110
65100 ?

Resumen de la ruta
Resumir los prefijos conserva los recursos del router y acelera el cálculo de la mejor ruta al
reducir el tamaño de la tabla. La integración también ofrece la ventaja de la estabilidad al
ocultar los flaps de ruta de los routers descendentes, reduciendo así la rotación de rutas.
Aunque la mayoría de los proveedores de servicios no aceptan prefijos superiores a /24
para IPv4 (de /25 a /32), Internet, en el momento de escribir este artículo, sigue teniendo
más de 780.000 rutas y sigue creciendo. La integración de rutas es necesaria para reducir el
tamaño de la tabla BGP de los routers de Internet.
El resumen de rutas BGP en los routers de borde BGP reduce el cálculo de rutas en los
routers del núcleo para las rutas recibidas o para las rutas anunciadas. En la Figura 11-11,
R3 resume todas las
Las rutas eBGP recibidas del AS 65100 y del AS 65200 para reducir el cálculo de rutas en el
R4 durante las interrupciones de enlace. En el caso de un flap de enlace en la red
10.13.1.0/24, R3 elimina todas las rutas del AS 65100 aprendidas directamente de R1 e
identifica los mismos prefijos de red a través de R2 con diferentes atributos de ruta (una
AS_Path más larga). R3 tiene que anunciar nuevas rutas a R4 debido a estas solapas, lo
cual es un desperdicio de ciclos de CPU porque R4 sólo recibe conectividad de R3. Si R3
resumiera el rango de prefijos de la red, R4 ejecutaría el algoritmo de mejor ruta una vez y
no necesitaría ejecutarlo durante los flaps del enlace 10.13.1.0/24.

Resumiendo
172.16.1.0/24 10.12.1.0 R2 10.23.1.0
172.16.2.0/24 /24 /24
172.16.3.0/24 AS 65200

10.13.1.0/24
R1 R310.34.1.0/24R4

AS 65100 AS 65400
Enlace de
aleteo
Figura 11-11 Resumen de rutas BGP que oculta las solapas de los enlaces
Existen dos técnicas para la integración de BGP: 11
■ Estática: Crear una ruta estática a Null0 para el prefijo de red de resumen y luego
anunciar el prefijo con una declaración de red. La desventaja de esta técnica es que
la ruta de resumen siempre se anuncia, incluso si las redes no están disponibles.
■ Dinámico: Configurar un prefijo de red de agregación. Cuando las rutas
componentes viables que coinciden con el prefijo de red de agregación entran en la
tabla BGP, entonces se crea el prefijo de agregación. El router de origen establece el
siguiente salto a Null0 como una ruta de descarte para el prefijo agregado para la
prevención de bucles.

En ambos métodos de agregación de rutas, se anuncia en BGP un nuevo prefijo de red con
una longitud de prefijo más corta. Como el prefijo agregado es una nueva ruta, el router de
resumen es el originador de la nueva ruta agregada.

Dirección agregada
La integración dinámica de rutas se realiza con el comando de configuración de la familia de
direcciones BGP aggregate-address network subnet-mask [summary-only] [as-set].
En la Figura 11-12 se elimina el enlace serie que aletea entre R1 y R3 para demostrar la
agregación de rutas BGP y los efectos de los comandos.

AS 65100

172.16.1.0 AS 65200 AS 65300


/24

172.16.2.0/24 10.12.1.0/24 10.23.1.0/24


R2R2R3
172.16.3.0
/24

Figura 11-12 Topología de resumen de BGP


El ejemplo 11-14 muestra las tablas BGP de R1, R2 y R3 antes de que se realice la
agregación de rutas. Las redes stub de R1 (172.16.1.0/24, 172.16.2.0/24 y 172.16.3.0/24) se
anuncian a través de todos los sistemas autónomos, junto con las direcciones loopback del
router (192.168.1.1/32, 192.168.2.2/32 y 192.168.3.3/32) y los enlaces peering (10.12.1.0/24 y
10.23.1.0/24).
Ejemplo 11-14 Tablas BGP para R1, R2 y R3 sin agregación

R1# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*10 .12.1.0/2410 .12.1. 200 65200 ?
*> 0.0 .0.0032768 ?
*> 10. 23.1.0/2410. 12.1.200 65200 ?
*> 1 7 2 .16.1.0/240.0 .0.0032768 ?
*> 1 7 2 .16.2.0/240.0 .0.0032768 ?
*> 1 7 2 .16.3.0/240.0 .0.0032768 ?
*> 1 9 2 .168.1.1/320.0 .0.0032768 ?
*> 1 9 2 .168.2.2/3210. 12.1.200 65200 ?
*> 1 9 2 .168.3.3/3210. 12.1.20 65200
65300 ?
R2# show bgp ipv4 unicast | begin Red
RedSiguiente HopMétrico LocPrf Peso Ruta
*10 .12.1.0/2410 .12.1. 100 65100 ?
*> 0.0 .0.0032768 ?
*10 .23.1.0/2410 .23.1. 300 65300 ?
*> 0.0 .0.0032768 ?
*> 1 7 2 .16.1.0/2410. 12.1.100 65100 ?
*> 1 7 2 .16.2.0/2410. 12.1.100 65100 ?
*> 1 7 2 .16.3.0/2410. 12.1.100 65100 ?
*> 1 9 2 .168.1.1/3210. 12.1.100 65100 ?
*> 1 9 2 .168.2.2/320.0 .0.0032768 ?
*> 1 9 2 .168.3.3/3210. 23.1.300 65300 ?

R3# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*> 10. 12.1.0/2410. 23.1.200 65200 ?
*10 .23.1.0/2410 .23.1. 200 65200 ?
*> 0.0 .0.0032768 ?
*> 1 7 2 .16.1.0/2410. 23.1.20
65200 65100 ?
*> 1 7 2 .16.2.0/2410. 23.1.20
65200 65100 ?
*> 1 7 2 .16.3.0/2410. 23.1.20
65200 65100 ?
*> 1 9 2 .168.1.1/3210. 23.1.20
65200 65100 ?
*> 1 9 2 .168.2.2/3210. 23.1.200 65200 ?
*> 1 9 2 .168.3.3/320.0 .0.0032768 ?

R1 agrega todas las redes stub (172.16.1.0/24, 172.16.2.0/24 y 172.16.3.0/24) en un prefijo


de red 172.16.0.0/20. R2 agrega todas las direcciones loopback del router en un prefijo
de red 172.16.0.0/20.
192.168.1.1/16. El ejemplo 11-15 muestra la configuración para el R1 que se ejecuta con la
familia de direcciones IPv4 por defecto y el R2 que se ejecuta sin la familia de direcciones
IPv4 por defecto.
Ejemplo 11-15 Configuración de la agregación de rutas BGP

R1# show running-config | section router bgp


router bgp 65100
bgp log-neighbor-changes
aggregate-address 172.16.0.0 255.255.240.0
redistribuir conectado
vecino 10.12.1.2 remote-as 65200

R2# show running-config | section router bgp


router bgp 65200 11
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.12.1.1 remote-as
65100
vecino 10.23.1.3 remote-as 65300
!
address-family ipv4
dirección agregada 192.168.0.0 255.255.0.0
redistribuir vecino
conectado 10.12.1.1
activar
vecino 10.23.1.3 activar
exit-address-family

El ejemplo 11-16 muestra las tablas de enrutamiento para R1, R2 y R3 después de que se
configure la agregación en R1 y R2.
Ejemplo 11-16 Tablas BGP para R1, R2 y R3 con agregación

R1# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*10 .12.1.0/2410 .12.1. 200 65200 ?
*> 0.0 .0.0032768 ?
*> 10. 23.1.0/2410. 12.1.200 65200 ?
*> 1 7 2 .16.0.0/200.0 .0.032768 i
*> 1 7 2 .16.1.0/240.0 .0.0032768 ?
*> 1 7 2 .16.2.0/240.0 .0.0032768 ?
*> 1 7 2 .16.3.0/240.0 .0.0032768 ?
*> 1 9 2 .168.0.0/1610. 12.1.200 65200 i
*> 1 9 2 .168.1.1/320.0 .0.0032768 ?
*> 1 9 2 .168.2.2/3210. 12.1.200 65200 ?
*> 1 9 2 .168.3.3/3210. 12.1.20 65200
65300 ?
R2# show bgp ipv4 unicast | begin Red
RedSiguiente HopMétrico LocPrf Peso Ruta
*10 .12.1.0/2410 .12.1. 100 65100 ?
*> 0.0 .0.0032768 ?
*10 .23.1.0/2410 .23.1. 300 65300 ?
*> 0.0 .0.0032768 ?
*> 1 7 2 .16.0.0/2010. 12.1.100 65100 i
*> 1 7 2 .16.1.0/2410. 12.1.100 65100 ?
*> 1 7 2 .16.2.0/2410. 12.1.100 65100 ?
*> 1 7 2 .16.3.0/2410. 12.1.100 65100 ?
*> 1 9 2 .168.0.0/160.0 .0.032768 i
*> 1 9 2 .168.1.1/3210. 12.1.100 65100 ?
*> 1 9 2 .168.2.2/320.0 .0.0032768 ?
*> 1 9 2 .168.3.3/3210. 23.1.300 65300 ?

R3# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*> 10. 12.1.0/2410. 23.1.200 65200 ?
*10 .23.1.0/2410 .23.1. 200 65200 ?
*> 0.0 .0.0032768 ?
*> 1 7 2 .16.0.0/2010. 23.1.20 65200
65100 i
*> 1 7 2 .16.1.0/2410. 23.1.20 65200
65100 ?
*> 1 7 2 .16.2.0/2410. 23.1.20 65200
65100 ?
*> 1 7 2 .16.3.0/2410. 23.1.20 65200
65100 ?
*> 1 9 2 .168.0.0/1610. 23.1.200 65200 i
*> 1 9 2 .168.1.1/3210. 23.1.20 65200
65100 ?
*> 1 9 2 .168.2.2/3210. 23.1.200 65200 ?
*> 1 9 2 .168.3.3/320.0 .0.0032768 ?

Observe que los prefijos de red 172.16.0.0/20 y 192.168.0.0/16 son visibles, pero los prefijos
de red componentes más pequeños todavía existen en todos los routers. El comando
aggregate-address anuncia la ruta agregada además de los prefijos de red componentes
originales.
El uso de la palabra clave opcional summary-only suprime los prefijos de red de los
componentes en el rango de la red resumida. El ejemplo 11-17 muestra la configuración
con la palabra clave summary-only.
Ejemplo 11-17 Configuración de agregación de rutas BGP con supresión

R1# show running-config | section router bgp


router bgp 65100
bgp log-neighbor-changes
aggregate-address 172.16.0.0 255.255.240.0 summary-
only redistribute connected
vecino 10.12.1.2 remote-as 65200

R2# show running-config | section router bgp


router bgp 65200
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.12.1.1 remote-as
65100
vecino 10.23.1.3 remote-as 65300
!
address-family ipv4
aggregate-address 192.168.0.0 255.255.0.0 summary-
only redistribute connected
vecino 10.12.1.1 activar
neighbor 10.23.1.3
activate exit-address-
family

El ejemplo 11-18 muestra la tabla BGP para R3 después de añadir la palabra clave
summary-only al comando de agregación. La red stub de R1 ha sido agregada en el prefijo de
red 172.16.0.0/20, mientras que el loopback de R1 y R2 ha sido agregado en el prefijo de red
192.168.0.0/16. Ninguna de las redes stub de R1 o las direcciones loopback de R1 o R2 son
visibles en R3.
Ejemplo 11-18 Tablas BGP para R3 con agregación y supresión

R3# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*> 10. 12.1.0/2410. 23.1.200 65200 ?
*10 .23.1.0/2410 .23.1. 200 65200 ?
11
*> 0.0 .0.0032768 ?
*> 1 7 2 .16.0.0/2010. 23.1.20 65200
65100 i
*> 1 9 2 .168.0.0/1610. 23.1.200 65200 i
*> 1 9 2 .168.3.3/320.0 .0.0032768 ?
El ejemplo 11-19 muestra la tabla BGP y la RIB de R2. Observe que las redes de bucle
invertido de los componentes han sido suprimidas por BGP y no son anunciadas por el
R2. Además, se ha instalado una ruta de descarte sumaria a Null0 como mecanismo de
prevención de bucles.
Ejemplo 11-19 BGP y RIB de R2 tras la agregación con supresión

R2# show bgp ipv4 unicast


La versión de la tabla BGP es 10, el ID del router local es 192.168.2.2
Códigos de estado: s suprimido, d amortiguado, h historial, * válido, >
mejor, i - interno, r RIB-fallo, S Stale, m multitrayecto, b
trayecto de respaldo, f RT-Filtro, x mejor-externo, a trayecto
adicional, c RIB-comprimido,
Códigos de origen: i - IGP, e - EGP, ? - incompleto
Códigos de validación RPKI: V válido, I no válido, N no encontrado

RedSiguiente HopMétrico LocPrf Peso Ruta


*10 .12.1.0/2410 .12.1. 100 65100 ?
*> 0.0 .0.0032768 ?
*10 .23.1.0/2410 .23.1. 300 65300 ?
*> 0.0 .0.0032768 ?
*> 1 7 2 .16.0.0/2010. 12.1.100 65100 i
*> 1 9 2 .168.0.0/160.0 .0.032768 i
s> 1 9 2 .168.1.1/32 10.12.1. 100 65100 ?
s> 1 9 2 .168.2.2/32 0.0.0. 0032768 ?
s> 1 9 2 .168.3.3/32 10.23.1. 300 65300 ?
R2# show ip route bgp | begin Gateway
La pasarela de último recurso no está configurada

172.16.0.0/20 está subredado, 1 subred


B172 .16.0.0 [20/0] vía 10.12.1.1, 00:06:18
B192 .168.0.0/16 [200/0], 00:05:37, Null0
192.168.1.0/32 está subredado, 1 subred
B192 .168.1.1 [20/0] vía 10.12.1.1, 00:02:15
192.168.3.0/32 está subredado, 1 subred
B192 .168.3.3 [20/0] vía 10.23.1.3, 00:02:15

El ejemplo 11-20 muestra que las redes stub de R1 han sido suprimidas, y que la ruta sumaria
dis- carda para la red 172.16.0.0/20 también ha sido instalada en la RIB.
Ejemplo 11-20 BGP y RIB de R1 tras la agregación con supresión

R1# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*10 .12.1.0/2410 .12.1. 200 65200 ?
*> 0.0 .0.0032768 ?
*> 10. 23.1.0/2410. 12.1.200 65200 ?
*> 1 7 2 .16.0.0/200.0 .0.032768 i
s> 1 7 2 .16.1.0/24 0.0.0. 0032768 ?
s 172.16.2.0/24 0.0.0.0 0 32768 ?
>
s 172.16.3.0/24 0.0.0.0 0 32768 ?
>
* 192.168.0.0/1 10.12.1.2 0 0 65 i
> 6 20
0
* 192.168.1.1/3 0.0.0.0 0 32768 ?
> 2
R1# show ip route bgp | begin Gateway
La pasarela de último recurso no está configurada

10.0.0.0/8 tiene una subred variable, 3 subredes, 2 máscaras


B10 .23.1.0/24 [20/0] vía 10.12.1.2, 00:12:50
172.16.0.0/16 tiene una subred variable, 7 subredes, 3 máscaras
B172 .16.0.0/20 [200/0], 00:06:51, Null0
B192 .168.0.0/16 [20/0] vía 10.12.1.2, 00:06:10

Agregado atómico
Las rutas agregadas actúan como nuevas rutas BGP con una longitud de prefijo más corta.
Cuando un enrutador BGP resume una ruta, no anuncia la información de AS_Path de
antes de la agregación. Los atributos de la ruta BGP como AS_Path, MED y comunidades
BGP no se incluyen en el nuevo anuncio BGP.
El atributo de agregación atómica indica que se ha producido una pérdida de
información de ruta. Para demostrarlo mejor, se ha eliminado la agregación de rutas
BGP anterior en R1 y se ha agregado a R2, de modo que ahora R2 está agregando las
redes 172.16.0.0/20 y 192.168.0/16 con supresión. El ejemplo 11-21 muestra la
configuración en el R2.
Ejemplo 11-21 Configuración de la agregación para 172.16.0.0/20 y 192.168.0.0/16

R2# show running-config | section router bgp


router bgp 65200
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.12.1.1 remote-as
65100
vecino 10.23.1.3 remote-as 65300
!
address-family ipv4
aggregate-address 192.168.0.0 255.255.0.0 summary-only
aggregate-address 172.16.0.0 255.255.240.0 summary-
only redistribute connected
vecino 10.12.1.1 activar
neighbor 10.23.1.3
activate exit-address-
family

El ejemplo 11-22 muestra las tablas BGP de R2 y R3. R2 está agregando y suprimiendo las
redes stub de R1 (172.16.1.0/24, 172.16.2.0/24 y 172.16.3.0/24) en la red 172.16.0.0/20. Los
prefijos de las redes componentes mantienen un AS_Path de 65100 en R2, mientras que la 11
red agregada 172.16.0.0/20 aparece generada localmente en R2.
Desde la perspectiva de R3, R2 no anuncia las redes stub de R1; en cambio, anuncia la red
172.16.0.0/20 como propia. El AS_Path para el prefijo de red 172.16.0.0/20 en el R3 es
simplemente el AS 65200 y no incluye el AS 65100.
Ejemplo 11-22 Tablas BGP de R2 y R3 con pérdida de atributos de ruta

R2# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*10 .12.1.0/2410 .12.1. 100 65100 ?
*> 0.0 .0.0032768 ?
*10 .23.1.0/2410 .23.1. 300 65300 ?
*> 0.0 .0.0032768 ?
*> 1 7 2 .16.0.0/200.0 .0.032768 i
s> 1 7 2 .16.1.0/2410. 12.1.100 65100 ?
s> 1 7 2 .16.2.0/2410. 12.1.100 65100 ?
s> 1 7 2 .16.3.0/2410. 12.1.100 65100 ?
*> 1 9 2 .168.0.0/160.0 .0.032768 i
s> 1 9 2 .168.1.1/3210. 12.1.100 65100 ?
s> 1 9 2 .168.2.2/320.0 .0.0032768 ?
s> 1 9 2 .168.3.3/3210. 23.1.300 65300 ?

R3# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*> 10. 12.1.0/2410. 23.1.200 65200 ?
*10 .23.1.0/2410 .23.1. 200 65200 ?
*> 0.0 .0.0032768 ?
*> 1 7 2 .16.0.0/2010. 23.1.200 65200 i
*> 1 9 2 .168.0.0/1610. 23.1.200 65200 i
*> 1 9 2 .168.3.3/320.0 .0.0032768 ?

El ejemplo 11-23 muestra la entrada explícita del prefijo 172.16.0.0/20 en el R3. La


información NLRI de la ruta indica que las rutas fueron agregadas en el AS 65200 por el
router con el RID 192.168.2.2. Además, el atributo de agregación atómica se ha establecido
para indicar una pérdida de atributos de ruta, como AS_Path en este escenario.
Ejemplo 11-23 Examen del atributo BGP para el atributo Atomic Aggregate

R3# show bgp ipv4 unicast 172.16.0.0


Entrada de la tabla de enrutamiento BGP para
172.16.0.0/20, versión 25 Rutas: (1 disponible, mejor
#1, tabla por defecto)
No se anuncia a ningún
compañero Refrescar la
época 2
65200, (agregado por 65200 192.168.2.2)
10.23.1.2 desde 10.23.1.2 (192.168.2.2)
Origen IGP, métrica 0, localpref 100, válido, externo, atomic-aggregate,
best rx pathid: 0, tx pathid: 0x0

Agregación de rutas con AS_SET


Para mantener el historial de información de la ruta BGP, se puede utilizar la palabra clave
opcional as-set con el comando aggregate-address. A medida que el enrutador genera la
ruta agregada, los atributos BGP de las rutas agregadas componentes se copian en ella. La
configuración del AS_Path de los prefijos originales se almacena en la parte AS_SET del
AS_Path. El AS_SET, que se muestra entre paréntesis, sólo cuenta como un salto, incluso si
hay varios ASs en la lista.
El ejemplo 11-24 muestra la configuración BGP actualizada de R2 para resumir ambas
redes con la palabra clave as-set.
Ejemplo 11-24 Configuración de la agregación conservando los atributos de BGP

R2# show running-config | section router bgp


router bgp 65200
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.12.1.1 remote-as
65100
vecino 10.23.1.3 remote-as 65300
!
address-family ipv4
aggregate-address 192.168.0.0 255.255.0.0 as-set summary-only
aggregate-address 172.16.0.0 255.255.240.0 as-set summary-only
redistribute connected
vecino 10.12.1.1 activar
neighbor 10.23.1.3
activate exit-address-
family

El ejemplo 11-25 muestra de nuevo la red 172.16.0.0/20, ahora que los atributos BGP se
propagarán en la nueva ruta. Observe que la información de AS_Path ahora contiene el AS
65100 como parte de la información.
Ejemplo 11-25 Verificación de que los atributos de ruta se inyectan en el agregado BGP

R3# show bgp ipv4 unicast 172.16.0.0


Entrada de la tabla de enrutamiento BGP para
172.16.0.0/20, versión 30 Rutas: (1 disponible, mejor
#1, tabla por defecto)
No se anuncia a ningún
compañero Refrescar la
época 2
65200 65100, (agregado por 65200 192.168.2.2)
10.23.1.2 desde 10.23.1.2 (192.168.2.2)
Origen incompleto, métrica 0, localpref 100, válido, externo,
best rx pathid: 0, tx pathid: 0x0
R3# show bgp ipv4 unicast | begin Red
RedSiguiente HopMétrico LocPrf Peso Ruta
*> 10. 12.1.0/2410. 23.1.200 65200 ?
*10 .23.1.0/2410 .23.1. 200 65200 ?
*> 0.0 .0.0032768 ?
*> 1 7 2 .16.0.0/2010. 23.1.200 65200 65100 ?
*> 1 9 2 .168.3.3/320.0 .0.0032768 ?

¿Se ha dado cuenta de que la red 192.168.0.0/16 ya no está presente en la tabla BGP de R3?
La razón de esto es que en R2, R2 está agregando todas las redes loopback de R1 (AS
11
65100), R2 (AS 65200) y R3 (AS 65300). Y ahora que R2 está copiando los atributos de ruta
BGP de todos los componentes en la información de AS_SET, la AS_Path para la red
192.168.0.0/16 contiene el AS 65300. Cuando el agregado se anuncia a R3, R3 descarta esa
ruta porque ve su propia AS_Path en el anuncio y piensa que es un bucle.
El ejemplo 11-26 muestra la tabla BGP de R2 y los atributos de ruta para la entrada
de red agregada 192.168.0.0/16.
Ejemplo 11-26 Ver las propiedades agregadas de 192.168.0.0/16

R2# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*10 .12.1.0/2410 .12.1. 100 65100 ?
*> 0.0 .0.0032768 ?
*10 .23.1.0/2410 .23.1. 300 65300 ?
*> 0.0 .0.0032768 ?
*> 1 7 2 .16.0.0/200.0 .0.0100 32768
65100 ?
s> 1 7 2 .16.1.0/2410. 12.1.100 65100 ?
s> 1 7 2 .16.2.0/2410. 12.1.100 65100 ?
s> 1 7 2 .16.3.0/2410. 12.1.100 65100 ?
*> 1 9 2 .168.0.0/160.0 .0.0100 32768 {65100,65300}
?
s> 1 9 2 .168.1.1/3210. 12.1.100 65100 ?
s> 1 9 2 .168.2.2/320.0 .0.0032768 ?
s> 1 9 2 .168.3.3/3210. 23.1.300 65300 ?
R2# show bgp ipv4 unicast 192.168.0.0
Entrada de la tabla de enrutamiento BGP para
192.168.0.0/16, versión 28 Rutas: (1 disponible,
mejor #1, tabla por defecto)
Anunciado a los grupos de
actualización: 1
Refrescar la época 1
{65100,65300}, (agregado por 65200 192.168.2.2)
0.0.0.0 desde 0.0.0.0 (192.168.2.2)
Origen incompleto, localpref 100, peso 32768, válido, agregado, local, mejor
pathid rx: 0, pathid tx: 0x0

R1 no instala la red 192.168.0.0/16 por las mismas razones que R3 no instala la red
192.168.0.0/16. R1 piensa que el anuncio es un bucle porque detecta AS65100 en el anuncio.
Esto se puede confirmar examinando la tabla BGP de R1, como se muestra en el Ejemplo
11-27.
Ejemplo 11-27 Tabla BGP de R1, con 192.168.0.0/16 descartada

R1# show bgp ipv4 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*10 .12.1.0/2410 .12.1. 200 65200 ?
*> 0.0 .0.0032768 ?
*> 10. 23.1.0/2410. 12.1.200 65200 ?
*> 1 7 2 .16.1.0/240.0 .0.0032768 ?
*> 1 7 2 .16.2.0/240.0 .0.0032768 ?
*> 1 7 2 .16.3.0/240.0 .0.0032768 ?
*> 1 9 2 .168.1.1/320.0 .0.0032768 ?
BGP multiprotocolo para IPv6
El BGP multiprotocolo (MP-BGP) permite a BGP transportar NLRI para múltiples
protocolos, como IPv4, IPv6 y redes privadas virtuales de capa 3 (L3VPN) de
Multiprotocol Label Switching (MPLS).
El RFC 4760 define las siguientes nuevas características:

■ Un nuevo modelo de identificador de familia de direcciones (AFI)

■ Nuevos atributos opcionales y no transitivos de BGPv4:

■ NLRI multiprotocolo alcanzable

■ Multiprotocolo inalcanzable NLRI

El nuevo atributo NLRI multiprotocolo alcanzable describe la información de la ruta IPv6,


y el atributo NLRI multiprotocolo inalcanzable retira la ruta IPv6 del servicio. Los atributos
son opcionales y no transitivos, por lo que si un router antiguo no entiende los atributos, la
información puede ser simplemente ignorada.
Todas las características y reglas del protocolo de enrutamiento vectorial de ruta
subyacente de IPv4 también se aplican a MP-BGP para IPv6. MP-BGP para IPv6 sigue
utilizando el mismo puerto TCP 179 conocido para la sesión de peering que BGP utiliza
para IPv4. Durante la negociación inicial de mensajes abiertos, los routers peer de BGP
intercambian capacidades. Las extensiones de MP-BGP incluyen un identificador de
familia de direcciones (AFI) que describe los protocolos soportados, junto con los campos
de atributos del identificador de familia de direcciones (SAFI) que describen si el prefijo se
aplica a la tabla de enrutamiento unicast o multicast:

■ IPv4 unicast: AFI: 1, SAFI: 1

■ IPv6 unicast: AFI: 2, SAFI: 1

La Figura 11-13 muestra una topología simple con tres AS diferentes y R2 formando una
sesión eBGP con R1 y R3. Las direcciones link-local se han configurado a partir del rango
link-local definido FE80::/10. Todos los enlaces de R1 están configurados para FE80::1,
todos los enlaces de R2 están configurados para FE80::2, y todos los enlaces de R3 están
configurados para FE80::3. Esta topología se utiliza a lo largo de esta sección.

AS AS AS
65200 65200 65300

2001:db8:0:1::/64 R1 2001:db8:0:12::/64 R2 2001:db8:0:23::/64 R3 2001:db8:0:3::/64

Loopback 0 Loopback 0 Loopback 0


2001:db8::1/128 2001:db8::2/128 2001:db8::3/128 11
Figura 11-13 Topología de muestra de IPv6
Configuración de IPv6
Todas las reglas de configuración de BGP demostradas anteriormente se aplican con
IPv6, excepto que la familia de direcciones IPv6 debe ser inicializada, y el vecino es
activado. Los routers que sólo tienen direcciones IPv6 deben definir estáticamente el RID
de BGP para permitir la formación de sesiones.
El protocolo utilizado para establecer la sesión BGP es independiente de los anuncios de
ruta AFI/SAFI. La sesión TCP utilizada por BGP es un protocolo de capa 4, y puede
utilizar una dirección IPv4 o IPv6 para formar una sesión de adyacencia e intercambiar
rutas. La publicidad de prefijos IPv6 sobre una sesión BGP IPv4 es factible pero está fuera
del alcance de este libro ya que se requiere una configuración adicional.

NOTA El direccionamiento unicast global único es el método recomendado para el peering


de BGP para evitar la complejidad operativa. El peering BGP utilizando la dirección link-local
puede introducir riesgos si la dirección no se asigna manualmente a una interfaz. Un fallo de
hardware o un movimiento de cableado cambiará la dirección MAC, resultando en una nueva
dirección link-local. Esto hará que la sesión falle porque la autoconfiguración de direcciones
sin estado generará una nueva dirección IP.

El ejemplo 11-28 muestra la configuración de BGP IPv6 para R1, R2 y R3. El peering utiliza
direccionamiento global unicast para establecer la sesión. El RID de BGP se ha
configurado con el formato IPv4 loopback utilizado en este libro. R1 anuncia todas sus
redes a través de la redistritación, y R2 y R3 utilizan la declaración de red para anunciar
todas sus redes conectadas.
Ejemplo 11-28 Configuración de IPv6 BGP

R1
router bgp 65100
bgp router-id
192.168.1.1 bgp log-
neighbor-changes
no bgp default ipv4-unicast
vecino 2001:DB8:0:12::2 remote-as 65200
!
address-family ipv6
vecino 2001:DB8:0:12::2 activar
redistribuir conectado
R2
router bgp 65200
bgp router-id
192.168.2.2 bgp log-
neighbor-changes
no bgp default ipv4-unicast
vecino 2001:DB8:0:12::1 remote-as 65100
vecino 2001:DB8:0:23::3 remote-as 65300
!
address-family ipv6
vecino 2001:DB8:0:12::1 activar
vecino 2001:DB8:0:23::3 activar
red 2001:DB8::2/128
red 2001:DB8:0:12::/64
red 2001:DB8:0:23::/64

R3
router bgp 65300
bgp router-id
192.168.3.3 bgp log-
neighbor-changes
no bgp default ipv4-unicast
vecino 2001:DB8:0:23::2 remote-as 65200
!
address-family ipv6
vecino 2001:DB8:0:23::2 activar red
2001:DB8::3/128
red 2001:DB8:0:3::/64
red 2001:DB8:0:23::/64

NOTA La capacidad de enrutamiento de unidifusión IPv4 se anuncia por defecto en IOS a


menos que el vecino se apague específicamente dentro de la familia de direcciones IPv4 o
globalmente dentro del proceso BGP con el comando no bgp default ipv4-unicast.

Los routers intercambian capacidades AFI durante la negociación inicial de la sesión BGP. El
comando show bgp ipv6 unicast neighbors ip-address [detail] muestra información detallada
sobre si las capacidades IPv6 fueron negociadas con éxito. El ejemplo 11-29 muestra los
campos que deben ser examinados para el establecimiento de la sesión IPv6 y el anuncio de
la ruta.
Ejemplo 11-29 Visualización de vecinos BGP para capacidades IPv6

R1# show bgp ipv6 unicast neighbors 2001:DB8:0:12::2


! Salida omitida por brevedad
El vecino BGP es 2001:DB8:0:12::2, AS remoto 65200, enlace externo
BGP versión 4, ID del enrutador remoto
192.168.2.2 Estado de BGP = Establecido,
activo durante 00:28:25
Última lectura 00:00:54, última escritura 00:00:34, el tiempo de espera es 180, el
intervalo de keepalive es
60 segundos
Sesiones con los vecinos:
1 activo, no es capaz de multisesión
(desactivado) Capacidades del vecino:
Actualización de la ruta: anunciada y recibida (nueva)
Capacidad ASN de cuatro octetos: anunciada y
recibida Familia de direcciones IPv6 Unicast: 11
anunciada y recibida Capacidad de actualización
mejorada: anunciada y recibida
..
Para la familia de direcciones:
IPv6 Unicast Sesión:
2001:DB8:0:12::2
Tabla BGP versión 13, vecino versión 13/0
Tamaño de la cola de salida : 0
Índice 1, bit de publicidad 0
1 miembro del grupo de actualización
La detección de pares lentos está desactivada
La dinámica de división de grupos de actualización de pares lentos está desactivada
SentRcvd
Actividad del prefijo :--------
Prefijos Actual: 35 (Consume 520 bytes)
Prefijos Total: 610

El comando show bgp ipv6 unicast summary muestra un resumen del estado de las
sesiones, incluyendo el número de rutas que se han intercambiado y el tiempo de
actividad de la sesión.
El ejemplo 11-30 muestra el estado de los vecinos IPv6 AFI para R2. Observe que las dos
adyacencias de vecinos han estado activas durante unos 25 minutos. El vecino
2001:db8:0:12::1 anuncia tres rutas, y el vecino 2001:db8:0:23::3 anuncia tres rutas.
Ejemplo 11-30 Verificación de una sesión BGP IPv6

R2# show bgp ipv6 unicast summary


Identificador del enrutador BGP 192.168.2.2, número de
AS local 65200 La versión de la tabla BGP es 19,
versión de la tabla de enrutamiento principal 19
7 entradas de red que utilizan 1176 bytes de memoria
8 entradas de la ruta utilizando 832 bytes de memoria
3/3 entradas de atributos BGP path/bestpath que utilizan 456 bytes de memoria
2 entradas de BGP AS-PATH utilizando 48 bytes de memoria
0 entradas de caché de mapa de ruta BGP utilizando 0 bytes de memoria
0 entradas de caché de lista de filtros BGP que
utilizan 0 bytes de memoria BGP que utiliza 2512
bytes de memoria en total
Actividad BGP 7/0 prefijos, 8/0 rutas, intervalo de escaneo 60 segundos

NeighborVAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


2001:DB8:0:12::1 4 6510035371900 00:25:083
2001:DB8:0:23::3 4 6530032371900 00:25: 113

El Ejemplo 11-31 muestra las tablas BGP de IPv6 unicast para R1, R2 y R3. Observe que
algunas de las rutas incluyen una dirección no especificada (::) como siguiente salto. Una
dirección no especificada indica que el enrutador local está generando el prefijo para la
tabla BGP. El valor de peso 32.768 también indica que el prefijo es originado localmente por
el router.
Ejemplo 11-31 Visualización de las tablas BGP IPv6
R1# show bgp ipv6 unicast
La versión de la tabla BGP es 13, el ID del router local es 192.168.1.1
Códigos de estado: s suprimido, d amortiguado, h historial, * válido, >
mejor, i - interno, r RIB-fallo, S Stale, m multitrayecto, b
trayecto de respaldo, f RT-Filtro, x mejor-externo, a trayecto
adicional, c RIB-comprimido,
Códigos de origen: i - IGP, e - EGP, ? - incompleto
Códigos de validación RPKI: V válido, I no válido, N no encontrado
RedSiguiente HopMétrico LocPrf Peso Ruta
*> 2001:DB8::1/128:: 032768 ?
*> 2001:DB8::2/1282001 :DB8:0:12::200 65200 i
*> 2001:DB8::3/1282001 :DB8:0:12::20 65200 65300 i
*> 2001:DB8:0:1::/64 ::032768 ?
*> 2 0 0 1 :DB8:0:3::/64 2001:DB8:0:12::20 65200 65300 i
*2001:DB8 :0:12::/64 2001:DB8:0:12:: 200 65200
i
*> :: 032768 ?
*> 2 0 0 1 :DB8:0:23::/64 2001:DB8:0:12::20 65200 65300 i

R2# show bgp ipv6 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*> 2001:DB8::1/1282001 :DB8:0:12::100 65100 ?
*> 2001:DB8::2/128:: 032768 i
*> 2001:DB8::3/1282001 :DB8:0:23::300 65300 i
*> 2 0 0 1 : D B 8 :0:1::/64 2001:DB8:0:12::100 65100 ?
*> 2 0 0 1 :DB8:0:3::/64 2001:DB8:0:23::300 65300 i
*> 2001:DB8:0:12::/64 ::032768 i
*2001 :DB8:0:12:: 100 65100 ?
*> 2001:DB8:0:23::/64 ::032768 i
2001:DB8:0:23:: 300 65300 i

R3# show bgp ipv6 unicast | begin Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*> 2001:DB8::1/1282001 :DB8:0:23::20 65200 65100 ?
*> 2001:DB8::2/1282001 :DB8:0:23::200 65200 i
*> 2001:DB8::3/128:: 032768 i
*> 2 0 0 1 : D B 8 :0:1::/64 2001:DB8:0:23::20 65200 65100 ?
*> 2001:DB8:0:3::/64 ::032768 i
*> 2 0 0 1 :DB8:0:12::/64 2001:DB8:0:23::200 65200 i
*> 2001:DB8:0:23::/64 ::032768 i

Los atributos de la ruta BGP para una ruta IPv6 se muestran con el comando show bgp
ipv6 unicast prefix/prefix-length. El ejemplo 11-32 muestra a R3 examinando la dirección
loopback de R1. Algunos de los campos comunes, como AS_Path, origen y preferencia
local, son idénticos a los de las rutas IPv4.
Ejemplo 11-32 Visualización de los atributos de la ruta BGP para una ruta IPv6

R3# show bgp ipv6 unicast 2001:DB8::1/128


Entrada de la tabla de enrutamiento BGP para
2001:DB8::1/128, versión 9 Rutas: (1 disponible,
mejor #1, tabla por defecto)
No se anuncia a ningún
compañero Refrescar la
11
época 2
65200 65100
2001:DB8:0:23::2 (FE80::2) desde 2001:DB8:0:23::2 (192.168.2.2)
Origen incompleto, localpref 100, válido, externo, mejor
rx pathid: 0, tx pathid: 0x0
El ejemplo 11-33 muestra las entradas de ruta BGP IPv6 para R2. Obsérvese que la
dirección del siguiente salto es la dirección local de enlace para la dirección de reenvío del
siguiente salto, que se resuelve mediante una búsqueda recurrente.
Ejemplo 11-33 RIB global para rutas IPv6 aprendidas de BGP

R2# show ipv6 route bgp


Tabla de enrutamiento IPv6 - por defecto - 10 entradas
Códigos: C - Conectado, L - Local, S - Estático, U - Ruta estática
por usuario B - BGP, HA - Agente doméstico, MR - Enrutador
móvil, R - RIP
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - Resumen ISIS, D - EIGRP, EX - EIGRP externo, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr -
Redirect RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext
1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-
eid a - Aplicación
B2001 :DB8::1/128 [20/0]
vía FE80::1,
GigabitEthernet0/0 B2001
:DB8::3/128 [20/0]
vía FE80::3,
GigabitEthernet0/1 B2001
:DB8:0:1::/64 [20/0]
vía FE80::1,
GigabitEthernet0/0 B2001
:DB8:0:3::/64 [20/0]
vía FE80::3, GigabitEthernet0/1

Resumen de IPv6
El mismo proceso para resumir o agregar rutas IPv4 ocurre con las rutas IPv6, y el formato es
idéntico excepto que la configuración se coloca bajo la familia de direcciones IPv6 usando
el comando aggregate-address prefix/prefix-length [summary-only] [as-set].
Volvamos a la implementación anterior de IPv6 pero ahora queremos resumir todas las
direcciones loopback (2001:db8:0:1/128, 2001:db8:0:2/128 y 2001:db8:0:3/128) junto con el
enlace peer- ing entre R1 y R2 (2001:db8:0:12/64) en R2. La configuración sería como se
muestra en el Ejemplo 11-34.
Ejemplo 11-34 Configuración de la agregación de BGP IPv6 en el R2

router bgp 65200


bgp router-id
192.168.2.2 bgp log-
neighbor-changes
vecino 2001:DB8:0:12::1 remote-as 65100
vecino 2001:DB8:0:23::3 remote-as 65300
!
address-family ipv4
no vecino 2001:DB8:0:12::1 activar
no vecino 2001:DB8:0:23::3 activar
exit-address-family
!
address-family
ipv6 bgp scan-
time 6
red 2001:DB8::2/128 red
2001:DB8:0:12::/64
aggregate-address 2001:DB8::/59 summary-only
vecino 2001:DB8:0:12::1 activar
vecino 2001:DB8:0:23::3 activar
exit-address-family

El ejemplo 11-35 muestra las tablas BGP en R1 y R3. Se puede ver que todas las rutas más
pequeñas han sido agregadas y suprimidas en 2001:db8::/59, como se esperaba.
Ejemplo 11-35 Verificación de la agregación de rutas IPv6

R3 show bgp ipv6 unicast | b Red


#
RedSiguiente Hop Métr Peso LocPrf Ruta
ica
*> 2001:DB8:: /592001:DB8:0:2 0 0 65200 i
3::2
*> 2001:DB8::3/128 :: 0 32768 i
*> 2001:DB8:0:3::/64 :: 0 32768 i
*> 2001:DB8:0:23::/64 :: 0 32768 i

R1 show bgp ipv6 unicast | b Red


#
RedSiguiente Hop Métr Peso LocPrf Ruta
ica
*> 2001:DB8:: /592001:DB8:0:1 0 0 65200 i
2::2
*> 2001:DB8::1/128 :: 0 32768 ?
*> 2001:DB8:0:1::/64 :: 0 32768 ?
*> 2001:DB8:0:12::/64 :: 0 32768 ?
*> 2001:DB8:0:23::/64 0 65200 65300
2001:DB8:0:12::2 i

El resumen de las direcciones IPv6 loopback (2001:db8:0:1/128, 2001:db8:0:2/128, y


2001:db8:0:3/128) es bastante sencillo, ya que todas entran en el rango de resumen IPv6
base 2001:db8:0:0::/64. El cuarto hexteto que comienza con un valor decimal de 1, 2 o 3
consumiría sólo 2 bits; el rango podría resumirse fácilmente en el rango de red
2001:db8:0:0::/62 (o 2001:db8::/62).
El enlace de peering entre R1 y R2 (2001:db8:0:12::/64) requiere pensar primero en
hexadecimales, en lugar de en valores decimales. El cuarto hexágono lleva un valor
decimal de 18 (no 12), que requiere 5 bits como mínimo. La Tabla 11-5 enumera los bits
necesarios para el resumen, la dirección sumaria IPv6 y las redes componentes en el rango
de resumen.

Tabla 11-5 Tabla de resumen de IPv6


Bits Dirección resumida Redes de componentes
necesarios
2 2001:db8:0:0::/62 2001:db8:0:0::/64 hasta 2001:db8:0:3::/64
3 2001:db8:0:0::/61 2001:db8:0:0::/64 hasta 2001:db8:0:7::/64 11
4 2001:db8:0:0::/60 2001:db8:0:0::/64 hasta 2001:db8:0:F::/64
5 2001:db8:0:0::/59 2001:db8:0:0::/64 hasta 2001:db8:0:1F::/64
6 2001:db8:0:0::/58 2001:db8:0:0::/64 hasta 2001:db8:0:3F::/64
Actualmente el enlace peering entre R2 y R3 (2001:db8:0:23::/64) no está siendo resumido y
suprimido, ya que todavía es visible en la tabla de enrutamiento de R1 en el Ejemplo 11-
35. El valor hexadecimal de 23 (es decir, 0x23) se convierte en un valor decimal de 35, que
requiere 6 bits. El rango de red resumido debe cambiarse a 2001:db8::/58 para que se
produzca la integración de la red 2001:db9:0:23::/64. El ejemplo 11-36 muestra el cambio de
configuración que se realiza en el R2.
Ejemplo 11-36 Configuración de un cambio para resumir la red 2001:db8:0:23::/64

R2# configurar terminal


Introduzca los comandos de configuración, uno por línea. Termine
con CNTL/Z. R2(config)# router bgp 65200
R2(config-router)# address-family ipv6 unicast
R2(config-router-af)# no aggregate-address 2001:DB8::/59 summary-only
R2(config-router-af)# aggregate-address 2001:DB8::/58 summary-only

El ejemplo 11-37 verifica que la dirección 2001:db8:0:23::/64 está ahora dentro del espacio de
direcciones agregadas y ya no se anuncia a R1.
Ejemplo 11-37 Verificación de la integración de la red 2001:db8:0:23::/64

R1# show bgp ipv6 unicast | b Red


RedSiguiente HopMétrico LocPrf Peso Ruta
*> 2001:DB8::/582001 :DB8:0:12::200 65200 i
*> 2001:DB8::1/128:: 032768 ?
*> 2001:DB8:0:1::/64 ::032768 ?
*> 2001:DB8:0:12::/64 ::032768 ?

Tareas de preparación del examen


Como se menciona en la sección "Cómo usar este libro" en la Introducción, tiene un par de
opciones para la preparación del examen: los ejercicios aquí, el capítulo 30, "Preparación
final", y las preguntas de simulación del examen en el software Pearson Test Prep Online.

Revisar todos los temas clave


Revise los temas más importantes del capítulo, señalados con el icono de Tema Clave en el
margen exterior de la página. La Tabla 11-6 enumera estos temas clave y el número de
página en el que se encuentra cada uno.

Tabla 11-6 Temas clave del capítulo 11


Elemento temático Descripción Página
clave
Sección Números de sistemas autónomos 242
Sección Atributos de la ruta 243
Párrafo Atributo BGP AS_Path 243
Párrafo Bases de datos y configuración de familias de 244
direcciones
Sección Comunicación entre routers 244
Elemento temático Descripción Página
clave
Figura 11-2 Sesiones de un solo bucle y de varios bucle de 245
BGP
Sección Tipos de sesión BGP 245
Sección eBGP 247
Sección Configuración básica de BGP 251
Sección Verificación de las sesiones BGP 253
Sección Anuncio del prefijo 255
Figura 11-9 Procesamiento de la base de datos BGP 258
Tabla 11-4 Campos de la tabla BGP 259
Lista Técnicas de resumen de BGP 263
Sección Dirección agregada 264
Párrafo Dirección agregada con resumen 267
Sección Agregado atómico 269
Sección Agregación de rutas con AS_SET 270
Sección BGP multiprotocolo para IPv6 273
Sección Configuración de IPv6 274
Sección Resumen de IPv6 278

Completar tablas y listas de memoria


No hay tablas de memoria en este capítulo.

Definir los términos clave


Defina los siguientes términos clave de este capítulo y compruebe sus respuestas en el glosario:

familia de direcciones, AS_Path, agregado atómico, sistema autónomo (AS), sesión eBGP,
sesión iBGP, tabla Loc-RIB, opcional no transitivo, opcional transitivo, protocolo de
enrutamiento vectorial de ruta, conocido discrecional, conocido obligatorio.

Utilice la referencia de comandos para comprobar su memoria


La Tabla 11-7 enumera los comandos importantes de este capítulo. Para poner a prueba
su memoria, cubra la parte derecha de la tabla con un papel, lea la descripción en la
parte izquierda y vea qué parte del comando puede recordar.

11
Tabla 11-7 Referencia de comandos
Tarea Sintaxis del comando
Inicializar el proceso de enrutamiento BGP router bgp as-number
Identificar un peer BGP con el que vecino ip-address remote-as as-number
establecer una sesión
Desactivar el modo de configuración no bgp default ip4-unicast
automática de la familia de direcciones
IPv4
Inicializar una familia de dirección-familia afi safi
direcciones y una subfamilia de
direcciones específicas
Activar un vecino BGP para una vecino ip-address activar
familia de direcciones específica
Anunciar una red a BGP red máscara de red máscara de subred
[route-map route-map-name]
Configurar un prefijo IPv4 agregado de aggregate-address network subnet-mask
BGP [sólo resumen] [as-set]
Configurar un prefijo IPv6 agregado de prefijo/dirección agregada/longitud de
BGP prefijo
[sólo resumen] [as-set]
Mostrar el contenido de la base de datos show bgp afi safi [red] [detallada]
BGP
Muestra un resumen de la tabla BGP show bgp afi safi summary
y de las sesiones de peering de los
vecinos
Muestra la configuración BGP show bgp afi safi neighbors ip-address
negociada con un peer específico y el
número de prefijos intercambiados con
ese peer
Mostrar la tabla BGP Adj-RIB-Out show bgp afi safi neighbor ip-address
para un vecino BGP específico rutas anunciadas

Referencias en este capítulo


RFC 1654, A Border Gateway Protocol 4 (BGP-4), por Yakov Rekhter y Tony Li.
https://www.ietf.org/rfc/rfc1654.txt, julio de 1994.
RFC 2858, Multiprotocol Extensions for BGP-4, por Yakov Rekhter, Tony Bates, Ravi
Chandra y Dave Katz. https://www.ietf.org/rfc/rfc2858.txt, junio de 2000.
RFC 4271, A Border Gateway Protocol 4 (BGP-4), Yakov Rekhter, Tony Li y Susan
Hares. https://www.ietf.org/rfc/rfc4271.txt, enero de 2006.
RFC 4760, Multiprotocol Extensions for BGP-4, por Yakov Rekhter, Tony Bates, Ravi
Chandra y Dave Katz. https://www.ietf.org/rfc/rfc4760.txt, enero de 2007.
RFC 4893, BGP Support for Four-octet AS Number Space, por Quaizar Vohra y Enke
Chen. https://www.ietf.org/rfc/rfc4893.txt, mayo de 2007.
IP Routing on Cisco IOS, IOS XE, and IOS XR, por Brad Edgeworth, Aaron Foss, and
Ramiro Garza Rios. Cisco Press, 2014.
Thi

También podría gustarte