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

CAPÍTULO 12
BGP avanzado
Este capítulo abarca los siguientes temas:

BGP flultihoming: Esta sección revisa los métodos para proporcionar resistencia a
través de conexiones BGP redundantes, junto con las consideraciones de diseño deseadas y
no deseadas para las conexiones de Internet y MPLS (sucursal y centro de datos).
Flatching condicional: Esta sección proporciona una visión general de cómo los
prefijos de red pueden ser condicionalmente emparejados con ACLs, listas de prefijos
y expresiones regulares.
Aletas de ruta: Esta sección explica la estructura de una hoja de ruta y cómo se
pueden combinar las coincidencias condicionales y las acciones condicionales para
filtrar o manipular las rutas.
Filtrado y flanqueo de rutas BGP: Esta sección amplía el funcionamiento de la

concordancia condicional y los mapas de ruta aplicando casos de uso del mundo real
para demostrar el filtrado o la manipulación de las rutas BGP.
Comunidades BGP: En esta sección se explica el atributo de ruta obligatoria conocida

de BGP y cómo se puede utilizar para etiquetar un prefijo para que los routers del
mismo sistema autónomo o de un sistema autónomo externo apliquen políticas de
ruta.
Comprensión de la selección de rutas de BGP: Esta sección describe la lógica utilizada
por BGP para identificar la mejor ruta cuando hay varias rutas instaladas en la tabla
BGP.
El Border Gateway Protocol (BGP) puede soportar cientos de miles de rutas, lo que lo
convierte en la opción ideal para Internet. Las organizaciones también utilizan BGP por su
flexibilidad y propiedades de ingeniería de tráfico. Este capítulo amplía el capítulo 11,
"Border Gateway Protocol (BGP)", explicando las características avanzadas de BGP y los
conceptos relacionados con el protocolo de enrutamiento BGP, como el multihoming BGP,
el filtrado de rutas, las comunidades BGP y la lógica para identificar la mejor ruta para un
prefijo de red específico.
"¿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 12-1 enumera los
principales títulos de este capítulo y las preguntas del cuestionario "¿Ya sé esto?" que
cubren el material de esos títulos para que pueda evaluar su conocimiento de estas áreas
específicas. Las respuestas al cuestionario "¿Ya sé esto?" aparecen en el Apéndice A,
"Respuestas al cuestionario "¿Ya sé esto? Preguntas del cuestionario".
Tabla 12-1 "¿Ya sé esto? "Sección de Temas Fundamentales a la pregunta
Sección de Temas Fundamentales Preguntas
BGP Multihoming 1
Correspondencia condicional 2–4
Mapas de rutas 5–6
Filtrado y manipulación de rutas BGP 7
Comunidades BGP 8
Comprensión de la selección de la ruta BGP 9–10
1. El enrutamiento en tránsito entre una red empresarial multihomed y un proveedor

de servicios no suele ser recomendable en qué casos? (Elija todas las que
correspondan).
a. Conexiones a Internet en los centros de datos
b. Conexiones a Internet en las sucursales
c. Centros de datos MPLS
d. Sucursales de MPLS
2. Verdadero o falso: Una ACL extendida utilizada para coincidir con las rutas
cambia el comportamiento si el protocolo de enrutamiento es un IGP en lugar de
BGP.
a. Verdadero
b. Falso
3. ¿Qué prefijos de red coinciden con el patrón de coincidencia de prefijos
10.168.0.0/13 ge 24? (Elija dos.)
a. 10.168.0.0/13
b. 10.168.0.0/24
c. 10.173.1.0/28
d. 10.104.0.0/24
4. ¿Cuál es la sintaxis correcta de una expresión regular para buscar una ruta
originada en el AS 300?
a. ^300_
b. $300!
c. _300_
d. _300$
5. ¿Qué ocurre cuando el mapa de ruta route-map QUESTION permit 20 no
contiene una sentencia de coincidencia condicional?
a. Las rutas se descartan y se registra un mensaje syslog.
b. Se descartan todas las rutas.
c. Se aceptan todas las rutas.
d. Se asigna un error al vincular la hoja de ruta a un peer BGP.
Capítulo 12: BGP avanzado 286
6. ¿Qué ocurre con una ruta que no coincide con la lista de prefijos PrefixRFC1918
cuando se utiliza el siguiente mapa de rutas?
route-map QUESTION deny 10
match ip address prefix-list PrefixRFC1918
route-map QUESTION permit 20
establecer la métrica 200
a. La ruta está permitida y la métrica se establece en 200.
b. La ruta está denegada.
c. La ruta está permitida.
d. La ruta está permitida, y la métrica por defecto se establece en 100.
7. Verdadero o falso: Una ACL AS_Path de BGP y una lista de prefijos pueden
aplicarse a un vecino al mismo tiempo.
a. Verdadero
b. Falso
8. ¿Cuál de las siguientes no es una comunidad BGP conocida?
a. No_Anuncio
b. Internet
c. No_Exportación
d. Ruta_privada
9. ¿Cuál de las siguientes técnicas es el segundo criterio de selección de la mejor ruta
de BGP?
a. Peso
b. Preferencia local
c. Origen
d. MED
10. Verdadero o falso: Para que MED se utilice como criterio de selección, las rutas
deben proceder de sistemas autónomos diferentes.
a. Verdadero
b. Falso
Temas de la Fundación
Internet se ha convertido en un componente vital para las empresas de hoy en día. La
conectividad a Internet es necesaria, como mínimo, para el correo electrónico y la
investigación. Además, algunas organizaciones alojan
servidores de comercio electrónico, utilizar telefonía de voz sobre IP (VoIP) o terminar
túneles VPN a través de conexiones MPLS privadas. Una organización debe incorporar
redundancias en la arquitectura de la red para garantizar que no haya puntos únicos de
fallo (SPOF) con la conectividad de la red para soportar las necesidades de la empresa.
Una empresa puede conectarse a Internet con una simple ruta por defecto utilizando una
única conexión. Sin embargo, si una empresa quiere utilizar varios proveedores de
servicios (SP) para
12
redundancia o rendimiento adicional, se requiere BGP. BGP es el protocolo de enrutamiento utilizado
en Internet.
El uso de BGP por parte de una empresa no se limita a la conectividad a Internet. Si la
empresa utiliza MPLS L3VPN de un proveedor de servicios, probablemente esté
utilizando BGP para intercambiar las redes LAN con el proveedor de servicios. Las
rutas suelen redistribuirse entre BGP y el protocolo de enrutamiento basado en la LAN.
En ambos casos, BGP se utiliza en el extremo de la red (Internet o WAN) y tiene
conexiones redundantes para garantizar una red fiable. Se
proporciona una selección avanzada de rutas y conectividad para una organización. Este
capítulo se centra en la resolución de problemas de las arquitecturas de borde de BGP.
BGP Multihoming
El método más sencillo para proporcionar redundancia es proporcionar un segundo
circuito. La adición de un segundo circuito y el establecimiento de una segunda sesión
BGP a través de ese enlace peering se conoce como BGP multihoming porque hay
múltiples sesiones para aprender rutas y establecer conectividad. El comportamiento por
defecto de BGP es anunciar sólo la mejor ruta a la RIB, lo que significa que sólo se utiliza
una ruta para un prefijo de red cuando se reenvía el tráfico de red a un destino.
Resiliencia en los proveedores de servicios

Pueden producirse fallos de enrutamiento dentro de la red de un proveedor de servicios,
y algunas organizaciones optan por utilizar un SP diferente para cada circuito. Se puede
elegir un segundo proveedor de servicios por diversas razones, pero la elección suele
reducirse al coste, la disponibilidad de circuitos para ubicaciones remotas o la separación
del plano de control.
Al utilizar un SP diferente, si un SP tiene problemas en su red, el tráfico de red puede
seguir fluyendo a través del otro SP. Además, la adición de más SPs significa que el tráfico
puede seleccionar una ruta óptima entre los dispositivos debido al algoritmo de mejor
ruta de BGP, discutido más adelante en este capítulo.
La Figura 12-1 ilustra cuatro escenarios comunes de multihoming:
■ Escenario 1: R1 se conecta a R3 con el mismo SP. Este diseño tiene en cuenta los
fallos de enlace; sin embargo, un fallo en cualquiera de los routers o dentro de
la red de SP1 provoca un fallo en la red.
■ Escenario 2: R1 se conecta a R3 y R4 con el mismo SP. Este diseño tiene en cuenta

los fallos de enlace; sin embargo, un fallo en R1 o dentro de la red de SP1 provoca
un fallo de red.
■ Escenario 3: R1 se conecta a R3 y R4 con los diferentes SPs. Este diseño tiene en

cuenta los fallos de enlace y los fallos en la red de cualquiera de los dos SP, y puede
optimizar el tráfico de enrutamiento. Sin embargo, un fallo en R1 provoca un fallo
en la red.
■ Escenario 4: R1 y R2 forman una sesión iBGP entre ellos. R3 se conecta a SP1, y R4 se

conecta a SP2. Este diseño tiene en cuenta los fallos de enlace y los fallos en la red de
cualquiera de los dos SP, y puede optimizar el tráfico de enrutamiento.
SP1 AS
SP1 AS SP1 AS SP2 AS SP1 AS SP2 AS
65300
65300 65300 65400 65300 65400
R3 R3 R4 R3 R4
eBGP R3 R4
eB
eBGP
eBGP
e e e e
GP
B B B B
G G G G
R1 P R1 P P R1 P R1 R2
iBGP
AS AS 65100 AS 65100 AS 65100
65100
Escenario 1 Escenario Escenario Escenario 4
2 3
Figura 12-1 Escenarios comunes de BGP Multihoming
Enrutamiento de tránsito por Internet

Si una empresa utiliza BGP para conectarse con más de un proveedor de servicios, corre el
riesgo de que su sistema autónomo (AS) se convierta en un AS de tránsito. En la Figura 12-
2, el AS 500 se está conectando a dos proveedores de servicios diferentes (SP3 y SP4) por
razones de resiliencia.
SP1 SP2
AS100 AS200
SP3 SP4
AS300 AS400 100.64.1.0/24
Usua Internet Servid
rio or
R1 R2
R3
AS500
Figura 12-2 Enrutamiento de tránsito empresarial
Pueden surgir problemas si R1 y R2 utilizan la política de enrutamiento BGP por defecto.
Un usuario que se conecta a SP3 (AS 300) se dirige a través de la red de la empresa (AS
500) para llegar a un servidor que se conecta a SP4 (AS 400). SP3 recibe el prefijo
100.64.1.0/24 de AS 100 y AS 500. SP3 selecciona la ruta a través del AS 500 porque la
AS_Path es mucho más corta que pasar por las redes de SP1 y SP2.
La red del AS 500 está proporcionando enrutamiento de tránsito a todo el mundo en Internet,
lo que puede saturar los enlaces de peering del AS 500. Además de causar problemas a los
usuarios del AS 500, esta situación tiene un impacto en el tráfico de los usuarios que intentan
atravesar el AS 500.
Respuestas al cuestionario "¿Ya lo sé? ":

1 A, B, D 2 A 3 B, C 4 D 5 C 6 A 7 A 8 D 9 B 10 B
El enrutamiento en tránsito puede evitarse aplicando políticas de ruta BGP de salida que 12
sólo permitan anunciar las rutas BGP locales a otros sistemas autónomos. Esto se discute
más adelante en este capítulo, en la sección "Filtrado y manipulación de rutas BGP".
Rutas de tránsito de las sucursales

Un diseño de red adecuado debe tener en cuenta los patrones de tráfico para evitar un
enrutamiento subóptimo o bucles de enrutamiento. La Figura 12-3 muestra un diseño
multihomed que utiliza múltiples transportes para todos los sitios. Todos los routers están
configurados para que prefieran el transporte MPLS SP2 sobre el transporte MPLS SP1
(activo/pasivo). Todos los routers son iguales y anuncian todas las rutas vía eBGP a los
routers SP. Los routers no filtran ninguno de los prefijos, y todos los routers establecen la
preferencia local para MPLS SP2 a un valor más alto para enrutar el tráfico a través de él.
Enrutamiento determinista durante la conmutación por error

10.1.12.0/24
Sede central
R11 R12
MPLS MPLS
SP1 SP2
Rama
R31 R41 R51 R52
10.5.12.0/24
Sitio 3 Redes Sitio 4 Redes Sitio 5 Redes

10.3.0.0/16 10.4.0.0/16 10.5.0.0/16
Figura 12-3 Enrutamiento determinista

Cuando la red funciona como es debido, el tráfico entre los sitios utiliza la red SP
preferida (MPLS SP2) en ambas direcciones. Esto simplifica la resolución de problemas
cuando el flujo de tráfico es simétrico (la misma ruta en ambas direcciones) en
contraposición al reenvío asimétrico
(un trayecto diferente para cada dirección) porque hay que descubrir el trayecto completo
en ambas direcciones. El camino se considera determinista cuando el flujo entre los sitios
está predeterminado y es predecible.
Durante un fallo de enlace dentro de la red SP, existe la posibilidad de que un router de
rama se conecte al router de rama de destino a través de un router de rama intermedio. La
Figura 12-4 muestra el escenario de fallo con el R41 proporcionando conectividad de
tránsito entre el Sitio 3 y el Sitio 5.
Enrutamiento no determinista durante la conmutación por error
10.1.12.0/24
Sede central
R11 R12
MPLS MPLS
SP1 SP2
Rama
R31 R41 R51 R52
10.5.12.0/24
Sitio 3 Redes Sitio 4 Redes Sitio 5 Redes

10.3.0.0/16 10.4.0.0/16 10.5.0.0/16
Figura 12-4 Enrutamiento no determinista durante la conmutación por error

La conectividad de tránsito no planificada presenta los siguientes problemas:
■ Los circuitos del router de tránsito pueden saturarse porque fueron

dimensionados sólo para el tráfico de ese sitio y no para el tráfico que lo atraviesa.
■ Los patrones de enrutamiento pueden volverse impredecibles y no deterministas. En

este escenario, el tráfico desde el R31 puede fluir a través del R41, pero el tráfico de
retorno puede tomar una ruta diferente. La ruta podría ser muy diferente si el
tráfico se originara en un router diferente. Esto impide el enrutamiento determinista,
complica la resolución de problemas y puede hacer que el personal de su NOC se
sienta como si estuviera jugando a la ruleta cuando resuelve los problemas de la
red.
Los entornos multihomed deben configurarse de manera que los routers de las sucursales
no puedan actuar como routers de tránsito. En la mayoría de los diseños, el enrutamiento
en tránsito del tráfico de otra sucursal no es deseable, ya que el ancho de banda de la WAN
puede no estar dimensionado en consecuencia. El enrutamiento en tránsito puede evitarse
configurando el filtrado de rutas de salida en cada sucursal. En esencia, las sucursales no
anuncian lo que aprenden de la WAN, sino que anuncian sólo las redes que dan a la LAN.
Si se requiere un comportamiento de tránsito, se restringe a los centros de datos o a
ubicaciones específicas de la siguiente manera:
■ Un diseño adecuado de las rutas puede dar cabida a las interrupciones.
■ El ancho de banda se puede dimensionar en consecuencia.
■ El patrón de enrutamiento es bidireccional y predecible.
NOTA El enrutamiento de tránsito en el centro de datos u otras ubicaciones planificadas es

normal en los diseños empresariales, ya que han tenido en cuenta el ancho de banda.
Normalmente, esto se hace cuando una parte de las sucursales está disponible sólo con un
SP, y las otras sucursales se conectan con un SP diferente.
Correspondencia condicional 12
Aplicar cambios masivos a las rutas vecino por vecino (o interfaz por interfaz para IGPs)
no permite fácilmente el ajuste de la red. Esta sección revisa algunas de las técnicas
comunes usadas para hacer coincidir condicionalmente una ruta-usando listas de control
de acceso (ACLs), listas de prefijos, expresiones regulares (regex) y ACLs de rutas de AS.
Listas de control de acceso

Originalmente, las listas de control de acceso (ACL) estaban destinadas a filtrar los
paquetes que entraban o salían de una interfaz de red, de forma similar a la funcionalidad
de un cortafuegos básico. Hoy en día,
Las ACLs proporcionan una clasificación de paquetes para una variedad de características,
como la calidad de servicio (QoS), o para identificar redes dentro de los protocolos de
enrutamiento.
Las ACLs se componen de entradas de control de acceso (ACEs), que son entradas en la
ACL que identifican la acción a realizar (permitir o denegar) y la clasificación de paquetes
correspondiente. La clasificación de los paquetes comienza en la parte superior (secuencia
más baja) y procede hacia abajo (secuencia más alta) hasta que se identifica un patrón de
coincidencia. Una vez que se encuentra una coincidencia, la acción apropiada (permitir o
deny), y el procesamiento se detiene. Al final de cada ACL hay una ACE de denegación
implícita, que deniega todos los paquetes que no coinciden con los anteriores en la ACL.
NOTA La ubicación de las ACEs dentro de una ACL es importante, y pueden producirse
consecuencias no deseadas si las ACEs están desordenadas.
Las ACL se clasifican en dos categorías:
■ ACLs estándar: Definen los paquetes basándose únicamente en la red de origen.
■ ACLs extendidas: Definen los paquetes en función del origen, el destino, el protocolo,
el puerto o una combinación de otros atributos de los paquetes. Este libro se ocupa
del enrutamiento y limita el alcance de las ACL al origen, el destino y el protocolo.
Los ACLS estándar utilizan una entrada numerada 1-99, 1300-1999, o una ACL con nombre. Extendido
Las ACLs utilizan una entrada numerada 100-199, 2000-2699, o una ACL con nombre. Las
ACLs con nombre proporcionan relevancia a la funcionalidad de la ACL, pueden ser
utilizadas con ACLs estándar o extendidas, y son generalmente preferidas.
ACL estándar
A continuación se describe el proceso de definición de una ACL estándar:
Paso 1. Defina la ACL mediante el comando ip access-list standard {acl-number |

acl-name} y colocar la CLI en el modo de configuración de ACL.
Paso 2. Configure la entrada ACE específica con el comando [sequence] {permit |
deny } source source-wildcard. En lugar de utilizar source-wildcard, la
palabra clave any sustituye a 0.0.0.0, y el uso de la palabra clave host se
refiere a una dirección IP /32, de modo que se puede omitir el source-
wildcard.
La Tabla 12-2 proporciona ejemplos de entradas ACL desde el modo de
configuración ACL y especifica las redes que coincidirían con una ACL estándar.
Tabla 12-2 Entradas estándar de ACL a red
Entrada ACE Redes
permitir cualquier Permite todas las redes
permit 172.16.0.0 0.0.255.255 Permite todas las redes en el rango
172.16.0.0
permit host 192.168.1.1 Sólo permite la red 192.168.1.1/32
ACLs extendidas
El siguiente es el proceso para definir una ACL extendida:
Paso 1. Defina la ACL mediante el comando ip access-list extended {acl-number |

acl-name} y colocar la CLI en el modo de configuración de ACL.
Paso 2. Configure la entrada ACE específica con el comando [sequence] {permit |
deny} protocol source source-wildcard destination destination-wildcard.
El comportamiento para seleccionar un prefijo de red con una ACL
extendida varía dependiendo de si el protocolo es un IGP (EIGRP, OSPF o
IS-IS) o BGP.
Selección de la red IGP

Cuando se utilizan ACLS para la selección de redes IGP, los campos de origen de la ACL se
utilizan para identificar la red, y los campos de destino identifican la longitud de prefijo más
pequeña permitida en el rango de la red. La Tabla 12-3 proporciona ejemplos de entradas
ACL desde el modo de configuración ACL y especifica las redes que coincidirían con la ACL
extendida. Observe que la sutil diferencia en el comodín de destino para la red 172.16.0.0
afecta a los rangos de red que se permiten en la segunda y tercera filas de la tabla.
Tabla 12-3 ACL ampliada para la selección de rutas IGP

Entrada ACE Redes
permit ip any any Permite todas las redes
permit ip host Permite todas las redes en el rango
172.16.0.0 host 172.16.0.0/12
255.240.0.0
permit ip host Permite todas las redes en el rango
172.16.0.0 host 172.16.0.0/16
255.255.0.0
permit host 192.168.1.1 Sólo permite la red 192.168.1.1/32
Selección de red BGP

Las ACLs extendidas reaccionan de forma diferente cuando coinciden con rutas BGP que
cuando coinciden con rutas IGP. Los campos de origen coinciden con la porción de red de
la ruta, y los campos de destino coinciden con la máscara de red, como se muestra en la
Figura 12-5. Hasta la introducción de las listas de prefijos, las ACLs extendidas eran el
único criterio de coincidencia utilizado con BGP.
permit protocol source source-wildcard destination destination-wildcard
Coincide con las redes Coincide con la máscara de la red

Figura 12-5 Coincidencias de ACL extendidas de BGP
La Tabla 12-4 demuestra el concepto de comodín para la red y la máscara de subred.
Tabla 12-4 ACL ampliada para la selección de rutas BGP 12
ACL ampliado Coincide con estas redes
permit ip 10.0.0.0 0.0 Sólo permite la red 10.0.0.0/16
255.255.0.0 0.0.0.0
permit ip 10.0.0.0 0.0.255.0 Permite cualquier red 10.0.x.0
255.255.255.0 0.0.0.0 con una longitud de prefijo
/24
permit ip 172.16.0.0 0.0.255.255 Permite cualquier red 172.16.x.x
255.255.255.0 0.0.0.255 con una longitud de prefijo de
/24 a /32
permit ip 172.16.0.0 0.0.255.255 Permite cualquier red 172.16.x.x
255.255.255.128 0.0.0.127 con una longitud de prefijo de
/25 a /32
Coincidencia de prefijos
Las listas de prefijos proporcionan otro método de identificación de redes en un
protocolo de enrutamiento. Una lista de prefijos identifica una dirección IP específica,
una red o un rango de redes y permite la selección de múltiples redes con una variedad
de longitudes de prefijos utilizando una especificación de coincidencia de prefijos.
Muchos ingenieros de redes prefieren esto sobre el método de selección de redes ACL.
Una especificación de coincidencia de prefijo contiene dos partes: un patrón de bits de alto
orden y un recuento de bits de alto orden, que determina los bits de alto orden en el patrón
de bits que deben coincidir. Algunos documentos se refieren al patrón de bits de alto
orden como la dirección o la red y al recuento de bits de alto orden como la longitud o la
longitud de la máscara.
En la Figura 12-6, la especificación de coincidencia de prefijo tiene el patrón de bits de
alto orden 192.168.0.0 y la cuenta de bits de alto orden 16. El patrón de bits de alto orden
se ha convertido a binario para demostrar dónde se encuentra el recuento de bits de alto
orden. Debido a que no hay parámetros adicionales de longitud de coincidencia
incluidos, el conteo de bits de alto orden es una coincidencia exacta.
Recuento de
Patrón de bits de
alto orden (red) bits de alto
orden (longitud)
Coincidencia 192.168.0.0/16
de prefijos
Prefijo
Longitud del
en
prefijo (negrita
binario
en el prefijo)
Prefijo: 192.168.0.0/16 11000000 00000000 1

10101000 00000000 6
Límite del
Bits de alto orden 16 recuento de bits
de alto orden
Figura 12-6 Patrón básico de
coincidencia de prefijos
En este punto, la lógica de la especificación del prefijo es idéntica a la funcionalidad de
una lista de acceso. La verdadera potencia y flexibilidad viene en el uso de los
parámetros de longitud de coincidencia para identificar múltiples redes con longitudes
de prefijo específicas con una declaración. Las opciones del parámetro de longitud
coincidente son
■ le: Menor o igual que, <=
■ ge: Mayor o igual que, >=

La Figura 12-7 muestra la especificación de coincidencia de prefijo con el patrón de bits de alto
orden 10.168.0.0 y la cuenta de bits de alto orden 13; la longitud de coincidencia del prefijo debe
ser mayor o igual a 24.
Recuento de bits
de alto orden
(longitud)
Patrón de bits de Parámetros de
alto orden (red)
longitudes de
coincidencia
Coincidencia 10.168.0.0/13 ge 24
de prefijos
Longitud del
prefijo (negrita
Prefijo
en el prefijo)
en
binario
Prefijo: 10.168.0.0/13 000010 101 0 000000 00000000 1

10 01 0 00 3
10.168.0.0/24 0
000010 101 0 000000 00000000 2
10.173.1.0/28 10 01 0 00 4
0
10.104.0.0/24
000010 101 1 000000 0000000 2
10 01 0 00 0 del
Límite 8
1 recuento de bits
Bits de alto orden 13
de alto orden
Figura 12-7 Patrón de coincidencia de prefijos con parámetros de longitud de coincidencia
El prefijo 10.168.0.0/13 no cumple el parámetro de longitud de coincidencia porque la longitud
del prefijo es inferior al mínimo de 24 bits, mientras que el prefijo 10.168.0.0/24 sí cumple el
parámetro de longitud de coincidencia. El prefijo 10.173.1.0/28 cumple los requisitos porque los
primeros 13 bits coinciden con el patrón de bits de orden superior y la longitud del prefijo está
dentro del parámetro de longitud coincidente. El prefijo 10.104.0.0/24 no califica porque el patrón
de bits de alto orden no coincide con el conteo de bits de alto orden.
La Figura 12-8 muestra una especificación de coincidencia de prefijo con el patrón de bits de
alto orden 10.0.0.0, el recuento de bits de alto orden 8 y la longitud de coincidencia entre 22
y 26.
Recuento de bits
de alto orden
(longitud)
Patrón de bits de Parámetros de

alto orden (red)
longitudes de
coincidencia
Coincidencia 10.0.0.0/8 ge 22 le 26
de prefijos
Prefijo bin
en ari
o
Longitud del
prefijo (negrita
en el prefijo)
Prefijo: 10.0.0.0/8 000010 00000000 00000000 00000000 8

10
10.0.0.0/24
000010 00000000 00000000 00000000 2
10 4
10.0.0.0/30
000010 00000000 00000000 00000000 3
10 0
Límite del
recuento de bits
Pedir Bits 8 de alto orden
Figura 12-8 Coincidencia de prefijos con prefijos no elegibles
El prefijo 10.0.0.0/8 no coincide porque la longitud del prefijo es demasiado corta. La red 12
10.0.0/24 cumple los requisitos porque el patrón de bits coincide y la longitud del prefijo
está entre 22 y 26. El prefijo 10.0.0.0/30 no coincide porque el patrón de bits es demasiado
largo. Cualquier prefijo que empiece por 10 en el primer octeto y que tenga una longitud de
prefijo entre 22 y 26 coincidirá.
NOTA La coincidencia con una longitud de prefijo específica que sea mayor que el recuento
de bits de orden superior requiere que el valor ge y el valor le coincidan.
Listas de prefijos
Las listas de prefijos pueden contener múltiples entradas de especificación de
coincidencia de prefijos que contienen una acción de permiso o denegación. Las listas de
prefijos se procesan en orden secuencial de forma descendente, y la primera coincidencia
de prefijos se procesa con la acción de permiso o denegación apropiada.
Las listas de prefijos se configuran con el comando de configuración global ip prefix-list
prefix-list- name [seq sequence-number] {permit | deny} high-order-bit-pattern/high-
order-bit-count [ge ge-value] [le le-value].
Si no se proporciona una secuencia, el número de secuencia se incrementa
automáticamente en 5, basándose en el número de secuencia más alto. La primera entrada
es la 5. La secuenciación permite borrar una entrada específica. Dado que las listas de
prefijos no se pueden volver a secuenciar, es aconsejable dejar espacio suficiente para
insertar números de secuencia más adelante.
IOS e IOS XE requieren que el valor ge sea mayor que el recuento de bits de alto orden y
que el valor le sea mayor o igual que el valor ge:
recuento de bits de alto orden < valor ge <= valor le
El ejemplo 12-1 proporciona un ejemplo de lista de prefijos llamada RFC1918 para todas
las redes en el rango de direcciones RFC 1918. La lista de prefijos sólo permite que
existan prefijos /32 en el rango de red 192.168.0.0 y que no existan en ningún otro rango
de red en la lista de prefijos.
Observe que la secuencia 5 permite todos los prefijos /32 en el patrón de bits
192.168.0.0/13, y la secuencia 10 niega todos los prefijos /32 en cualquier patrón de bits, y
las secuencias 15, 20 y 25 permiten rutas en los rangos de red apropiados. El orden de la
secuencia es importante para las dos primeras entradas para asegurar que sólo existen
prefijos /32 en la red 192.168.0.0 en la lista de prefijos.
Ejemplo 12-1 Ejemplo de lista de prefijos
ip prefix-list RFC1918 seq 5 permit 192.168.0.0/13 ge

32 ip prefix-list RFC1918 seq 10 deny 0.0.0/0 ge 32
ip prefix-list RFC1918 seq 15 permit 10.0.0.0/7 ge 8
ip prefix-list RFC1918 seq 20 permit 172.16.0.0/11 ge
12 ip prefix-list RFC1918 seq 25 permit 192.168.0.0/15
ge 16
Listas de prefijos IPv6

La lógica de coincidencia de prefijos funciona exactamente igual para las redes IPv6 que
para las redes IPv4. Lo más importante es recordar que las redes IPv6 se anotan en
hexadecimal y no en binario cuando se identifican rangos. Sin embargo, en última instancia,
todo funciona a nivel binario.
Las listas de prefijos IPv6 se configuran con el comando de configuración global ipv6
prefix-list prefix-list-name [seq sequence-number] {permit | deny} high-order-bit-
pattern/high- order-bit-count [ge ge-value] [le le-value].
El ejemplo 12-2 proporciona una lista de prefijos de muestra llamada PRIVATE-IPV6 para
todas las redes en el espacio de documentación y evaluación comparativa de IPv6.
Ejemplo 12-2 Ejemplo de lista de prefijos IPv6
ipv6 prefix-list PRIVATE-IPV6 seq 5 permit 2001:2::/48 ge 48

ipv6 prefix-list PRIVATE-IPV6 seq 10 permit 2001:db8::/32 ge
32
Expresiones regulares (regex)

Puede haber ocasiones en las que la coincidencia condicional de prefijos de red puede ser
demasiado complicada, y se prefiere identificar todas las rutas de una organización
específica. En este caso, la selección de la ruta puede hacerse utilizando un AS_Path de BGP.
Las expresiones regulares (regex) se utilizan para analizar el gran número de ASN
disponibles (4.294.967.295). Las expresiones regulares se basan en modificadores de consulta
utilizados para seleccionar el contenido adecuado. La tabla BGP puede ser analizada con
regex usando el comando show bgp afi safi regexp regex-pattern.
La Tabla 12-5 proporciona una breve lista y descripción de los modificadores de consulta regex más comunes.
Tabla 12-5 Modificadores de consulta RegEx

Modificador Descripción
_ (guión bajo) Coincide con un espacio
^ (caret) Indica el inicio de una cadena
$ (signo de dólar) Indica el final de una cadena
[] (paréntesis) Coincide con un solo carácter o con la anidación dentro de un
rango
- (guión) Indica un rango de números entre paréntesis
[^] (caret entre Excluye los caracteres que aparecen entre paréntesis
paréntesis)
() (paréntesis) Se utiliza para anidar los patrones de búsqueda
| (tubería) Proporciona la funcionalidad OR a la consulta
. (punto) Coincide con un solo carácter, incluyendo un espacio
* (asterisco) Coincide con cero o más caracteres o patrones
+ (signo de suma) Coincide con una o más instancias del carácter o patrón
? (signo de Coincide con una o ninguna instancia del carácter o patrón
interrogación)
Aprender regex puede llevar tiempo, pero los más comunes utilizados en BGP son ^, $ y _.
La Tabla 12-6 muestra algunas regex comunes de BGP.
Tabla 12-6 Expresiones regulares comunes de BGP

Expresión regular Significado
^$ Rutas de origen local
permiso ^200_ Sólo las rutas del vecino AS 200
permiso _200$ Sólo las rutas con origen en el AS 200
permiso _200_ Sólo las rutas que pasan por el AS 200
permitir ^[0-9]+ [0-9]+ [0-9]+? Rutas con tres o menos entradas AS_Path
NOTA La experiencia práctica es útil cuando se aprenden tecnologías como regex. Existen 12
servidores públicos llamados looking glasses que permiten a los usuarios iniciar sesión y ver
las tablas BGP. La mayoría de estos dispositivos son routers de Cisco, pero algunos son de
otros proveedores. Estos servidores permiten a los ingenieros de red ver si están anunciando
sus rutas a Internet como habían previsto y proporcionan un gran método para probar las
expresiones regulares en la tabla BGP de Internet.
Una rápida búsqueda en Internet proporcionará listados de sitios web de servidores de
miradas y rutas. Le sugerimos
Mapas de rutas
Los mapas de ruta proporcionan muchas características diferentes a una variedad de
protocolos de enrutamiento. En el nivel más simple, los mapas de ruta pueden filtrar redes
de la misma manera que las ACL, pero también proporcionan una capacidad adicional a
través de la adición o modificación de los atributos de la red. Para influir en un protocolo
de enrutamiento, un mapa de ruta debe ser referenciado desde el protocolo de
enrutamiento. Los mapas de ruta son fundamentales para BGP porque son el componente
principal para modificar una política de enrutamiento única vecino por vecino.
Una hoja de ruta tiene cuatro componentes:
■ Número de secuencia: Dicta el orden de procesamiento de la hoja de ruta.
■ Criterios de coincidencia condicional: Identifica las características del prefijo (red,

atributo de ruta BGP, siguiente salto, etc.) para una secuencia específica.
■ Acción de procesamiento: Permite o deniega el prefijo.
■ Acción opcional: Permite realizar manipulaciones, dependiendo de cómo se

referencie la hoja de ruta en el router. Las acciones pueden incluir la
modificación, adición o eliminación de las características de la ruta.
Un mapa de ruta utiliza la sintaxis del comando route-map route-map-name

[permit | deny] [sequence-number]. Las siguientes reglas se aplican a las
declaraciones de mapa de ruta:
■ Si no se proporciona una acción de procesamiento, se utiliza el valor por defecto permiso.
■ Si no se proporciona un número de secuencia, el número de secuencia se

incrementa por 10 automáticamente.
■ Si no se incluye una sentencia que coincida, se asocia un prefijo implícito a la

sentencia.
■ El procesamiento dentro de una hoja de ruta se detiene después de que se

hayan procesado todas las acciones opcionales (si están configuradas) tras
coincidir con un criterio de coincidencia condicional.
El ejemplo 12-3 proporciona un ejemplo de mapa de ruta para demostrar los cuatro
componentes de un mapa de ruta mostrados anteriormente. El criterio de coincidencia
condicional se basa en rangos de red especificados en una ACL. Se han añadido
comentarios a este ejemplo para explicar el comportamiento del mapa de ruta en cada
secuencia.
Ejemplo 12-3 Ejemplo de mapa de ruta
route-map EXAMPLE permit 10

match ip address ACL-ONE
! Los prefijos que coinciden con ACL-ONE están permitidos. El mapa de ruta completa
el procesamiento cuando se produce una coincidencia
route-map EXAMPLE deny 20

match ip address ACL-TWO
! Los prefijos que coinciden con ACL-TWO son denegados. El mapa de ruta completa el
procesamiento cuando hay una coincidencia
route-map EXAMPLE permit

30 match ip address ACL-
THREE set metric 20
! Los prefijos que coinciden con ACL-THREE están permitidos y modifican la métrica.
El mapa de ruta se completa
Procesamiento en caso de coincidencia

! Como no se ha especificado un criterio de coincidencia, se permiten todos los demás
prefijos
! Si esta secuencia no estuviera configurada, todos los demás prefijos caerían debido
a la
Negación implícita para todos los mapas de ruta
NOTA Cuando elimine una declaración de mapa de ruta específica, incluya el número de
secuencia para evitar que se elimine todo el mapa de ruta.
Correspondencia condicional
Ahora que se han explicado los componentes y el orden de procesamiento de una hoja de
ruta, esta sección amplía cómo se puede hacer coincidir una ruta. La Tabla 12-7
proporciona la sintaxis de los comandos para los métodos más comunes de coincidencia
condicional de prefijos y describe su uso. Como puede ver, hay un número de opciones
disponibles.
Tabla 12-7 Opciones de coincidencia condicional

Comando del partido Descripción
match as-path acl-number Selecciona los prefijos basándose en una
consulta regex para aislar el ASN en la
ruta de AS del atributo de ruta (PA) de
BGP. Las ACL de la ruta de AS están
numeradas
1 a 500. Este comando permite múltiples
variables de coincidencia.
match ip address {acl-number | acl-name} Selecciona los prefijos basándose en los
criterios de selección de red definidos
en la ACL. Este comando permite
múltiples variables de coincidencia.
match ip address prefix-list prefix-list- Selecciona los prefijos basándose en
name los criterios de selección de prefijos.
Este comando permite múltiples
variables de coincidencia.
Comando del partido Descripción

match local-preference local-preference Selecciona los prefijos basándose en la
preferencia local del atributo BGP. Este
comando permite múltiples variables 12
de coincidencia.
match métrica {1-4294967295 | externa Selecciona los prefijos en función de una
1-4294967295}[+- desviación] métrica que puede ser exacta, un rango o
una desviación aceptable.
match tag tag-value Selecciona prefijos basados en una
etiqueta numérica (0 a 4294967295) que
fue establecida por otro enrutador. Este
Condiciones condicionales múltiples
Si hay múltiples variables (ACLs, listas de prefijos, etiquetas, etc.) configuradas para una
secuencia de mapa de ruta específica, sólo una variable debe coincidir para que el prefijo
califique. La lógica booleana utiliza un operador OR para esta configuración.
En el Ejemplo 12-4, la secuencia 10 requiere que un prefijo pase ACL-ONE o ACL-TWO.
Observe que la secuencia 20 no tiene una declaración de coincidencia, por lo que todos
los prefijos que no pasen la secuencia 10 calificarán y serán denegados.
Ejemplo 12-4 Ejemplo de mapa de ruta con múltiples variables de coincidencia

match ip address ACL-ONE ACL-TWO
!
NOTA En el ejemplo 12-4, la secuencia 20 es redundante debido a la denegación implícita de

cualquier prefijo que no coincida con la secuencia 10.
Si hay múltiples opciones de coincidencia configuradas para una secuencia de mapa de

ruta específica, ambas opciones de coincidencia deben cumplirse para que el prefijo pueda
ser calificado para esa secuencia. La lógica booleana utiliza un operador AND para esta
configuración.
En el Ejemplo 12-5, la secuencia 10 requiere que el prefijo coincida con ACL-ONE y que la
métrica sea un valor entre 500 y 600. Si el prefijo no califica para ambas opciones de
coincidencia, el prefijo no califica para la secuencia 10 y es denegado porque no existe otra
secuencia con una acción de permiso.
Ejemplo 12-5 Ejemplo de mapa de ruta con múltiples opciones de coincidencia

match metric 550 +- 50
Correspondencia compleja
Algunos ingenieros de redes encuentran los mapas de ruta demasiado complejos si los
criterios de coincidencia condicional utilizan una ACL, una ACL de ruta de AS o una lista
de prefijos que contiene una sentencia deny. El ejemplo 12-6 muestra una configuración
donde la ACL utiliza una sentencia deny para el rango de red 172.16.1.0/24.
Las configuraciones de lectura de este tipo deben seguir primero el orden de la
secuencia y en segundo lugar los criterios de coincidencia condicional, y sólo después
de que se produzca una coincidencia se debe utilizar la acción de procesamiento y la
acción opcional. La coincidencia de una declaración de denegación en los criterios de
coincidencia condicional excluye la ruta de esa secuencia en el mapa de rutas.
El prefijo 172.16.1.0/24 es denegado por ACL-ONE, lo que implica que no hay una
coincidencia en las secuencias 10 y 20; por lo tanto, la acción de procesamiento
(permitir o denegar) no es necesaria. La secuencia 30 no contiene una cláusula de
coincidencia, por lo que las rutas restantes están permitidas.
El prefijo 172.16.1.0/24 pasaría en la secuencia 30 con la métrica establecida en 20. El
prefijo 172.16.2.0/24 coincidiría con ACL-ONE y pasaría en la secuencia 10.
Ejemplo 12-6 Mapas de ruta de coincidencia compleja
ip access-list standard ACL-

ONE deny172 .16.1.0
0.0.255
permit 172.16.0.0 0.0.255.255

ONE
!
!
establecer la métrica 20
NOTA Los mapas de ruta se procesan utilizando un orden particular de evaluación: la

secuencia, los criterios de coincidencia condicional, la acción de procesamiento y la acción
opcional en ese orden. Cualquier declaración de denegación en el componente de coincidencia
está aislada de la acción de la secuencia del mapa de ruta.
Acciones opcionales
Además de permitir el paso del prefijo, los mapas de ruta pueden modificar los
atributos de la ruta. La Tabla 12-8 ofrece un breve resumen de las modificaciones de
atributos más populares.
Tabla 12-8 Acciones del conjunto de mapas de ruta

Acción de ajuste Descripción
set as-path prepend {as-number-pattern | Precede la ruta del AS para el prefijo de
last-as 1-10} red con el patrón especificado o de
múltiples iteraciones de un AS vecino.
set ip next-hop { dirección-ip | dirección-par Establece la dirección IP del siguiente
| salto para cualquier prefijo que coincida.
auto } La manipulación dinámica de BGP utiliza
las palabras clave peer-address o self.
set local-preference 0-4294967295 Establece la preferencia local de BGP PA.
set metric {+valor | -valor | valor} Modifica la métrica existente o
establece la métrica para una ruta.
(donde los parámetros de valor son 0-
4294967295)
Acción de ajuste Descripción
set origin {igp | incompleto} Establece el origen BGP PA.
set tag tag-value Establece una etiqueta numérica (0-
4294967295) para la identificación de 12
redes por parte de otros routers
fijar el peso 0-65535 Establece el peso de BGP PA.
La palabra clave de continuar
El comportamiento predeterminado de la hoja de ruta procesa las secuencias de la hoja de
ruta en orden, y tras la primera coincidencia, ejecuta la acción de procesamiento, realiza
cualquier acción opcional (si es factible) y detiene el procesamiento. Esto evita que se
procesen múltiples secuencias de mapas de ruta.
Agregar la palabra clave continue a un mapa de ruta permite que el mapa de ruta continúe
procesando otras secuencias de mapas de ruta. El ejemplo 12-7 proporciona una
configuración básica. El prefijo de red 192.168.1.1 coincide con las secuencias 10, 20 y 30.
Debido a que la palabra clave continue fue añadida a la secuencia 10, la secuencia 20 se
procesa, pero la secuencia 30 no lo hace porque un com- mandante continue no estaba
presente en la secuencia 20. El prefijo 192.168.1.1 está permitido, y se modifica para que la
métrica sea 20, con la dirección de siguiente salto 10.12.1.1.
Ejemplo 12-7 Mapa de ruta con la palabra clave continue
ip access-list standard ACL-ONE

permit 192.168.1.1 0.0.0
permit 172.16.0.0 0.0.255.255
!
ip access-list standard ACL-TWO
permit 192.168.1.1 0.0.0
permit 172.31.0.0 0.0.255.255
!
ONE set metric 20
continuar
!
TWO set ip next-hop
10.12.1.1
!
set ip next-hop 10.13.1.3
NOTA El comando continue no se suele utilizar porque añade complejidad a la hora de solucionar los
problemas de los mapas de ruta.
Filtrado y manipulación de rutas BGP

El filtrado de rutas es un método para identificar selectivamente las rutas anunciadas o
recibidas de los routers vecinos. El filtrado de rutas puede utilizarse para manipular los
flujos de tráfico, reducir
utilización de la memoria, o mejorar la seguridad. Por ejemplo, es común que los ISPs
desplieguen filtros de ruta en los peerings BGP de los clientes. Asegurarse de que sólo se
permiten las rutas del cliente a través del enlace peering evita que el cliente se convierta
accidentalmente en un AS de tránsito en Internet.
La Figura 12-9 muestra la lógica completa de procesamiento de rutas BGP. Observe que las
políticas de enrutamiento ocurren en la recepción de la ruta de entrada y en el anuncio de la
ruta de salida.
Declaración de la Políticas de rutas de Rutas

red entrada Adj-RIB-
desde los
In
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 12-9 Procesamiento de políticas de ruta BGP
IOS XE proporciona cuatro métodos para filtrar rutas de entrada o salida para un peer
BGP específico. Estos métodos se pueden utilizar de forma individual o simultáneamente
con otros métodos:
■ Lista de distribución: Una lista de distribución implica el filtrado de prefijos de red

basado en una ACL estándar o extendida. Se asocia una denegación implícita a
cualquier prefijo no permitido.
■ Lista de prefijos: Una lista de especificaciones de coincidencia de prefijos permite o

deniega prefijos de red de forma descendente, de forma similar a una ACL. Una
denegación implícita se asocia a cualquier prefijo no permitido.
■ ACL/filtrado de rutas de AS: Una lista de comandos regex permite permitir o

denegar un prefijo de red en función de los valores actuales de la ruta AS. Una
denegación implícita se asocia a cualquier prefijo no permitido.
■ Mapas de ruta: Los mapas de ruta proporcionan un método de coincidencia

condicional en una variedad de atributos de prefijo y de tomar una variedad de
acciones. Las acciones pueden ser un simple permiso o denegación; o pueden
incluir la modificación de los atributos de la ruta BGP. Una denegación implícita
se asocia a cualquier prefijo no permitido.
NOTA Un vecino BGP no puede utilizar una lista de distribución y una lista de prefijos al
mismo tiempo para recibir o anunciar rutas.
Las siguientes secciones explican cada una de estas técnicas de filtrado con más detalle. Imagine
un escenario simple con R1 (AS 65100) que tiene un solo peering eBGP con R2 (AS 65200), 12
que luego puede hacer peer con otros sistemas autónomos (como el AS 65300). La parte
relevante de la topología es que R1 hace peer con R2 y se centra en la tabla BGP de R1,
como se muestra en el Ejemplo 12-8, con énfasis en el prefijo de red y la ruta del AS.
Ejemplo 12-8 Tabla BGP de referencia
R1# show bgp ipv4 unicast | begin Red

RedSiguiente HopMétrico LocPrf Peso Ruta
*> 10. 3.3.0/2410. 12.1.2330 65200 65300 3003 ?
*10 .12.1.0/2410 .12.1. 2220 65200 ?
*> 0.0 .0.00 32768 ?
*> 10. 23.1.0/2410. 12.1.23330 65200 ?
*> 1 0 0 .64.2.0/2510. 12.1.2220 65200 ?
*> 1 0 0 .64.2.192/26 10. 12.1.2220 65200 ?
*> 1 0 0 .64.3.0/2510. 12.1.2220 65200 65300 300 ?
*> 1 9 2 .168.1.1/320.0 .0.00 32768 ?
*> 1 9 2 .168.2.2/3210. 12.1.2220 65200 ?
*> 1 9 2 .168.3.3/3210. 12.1.233330 65200 65300 ?
Filtrado de listas de distribución

Las listas de distribución permiten filtrar prefijos de red vecino por vecino, utilizando
ACLs estándar o extendidas. La configuración de una lista de distribución requiere el uso
del comando de configuración de la familia de direcciones BGP neighbor ip-address
distribute-list {acl-number | acl-name}.
{in|out}. Recuerde que las ACLs extendidas para BGP utilizan los campos de origen para
coincidir con la parte de red y los campos de destino para coincidir con la máscara de red.
El ejemplo 12-9 proporciona la configuración BGP de R1, que demuestra el filtrado con
listas de distribución. La configuración utiliza una ACL extendida llamada ACL-ALLOW
que contiene dos entradas. La primera entrada permite cualquier red que comience en el
rango 192.168.0.0 a 192.168.255.255 con cualquier longitud de red. La segunda entrada
permite redes que contengan el patrón 100.64.x.0 con una longitud de prefijo de /26 para
demostrar las capacidades de comodín de una ACL extendida con BGP. La lista de
distribución se asocia con el R2
Sesión BGP.
Ejemplo 12-9 Configuración de la lista de distribución de BGP
R1
ip access-list extended ACL-ALLOW
permit ip 192.168.0.0 0.0.255.255 host 255.255.255.255
permit ip 100.64.0.0 0.0.0.255.0 host 255.255.255.128
!
router bgp 65100
address-family
ipv4
neighbor 10.12.1.2 distribute-list ACL-ALLOW in
El ejemplo 12-10 muestra la tabla de enrutamiento de R1. R1 inyecta dos rutas locales en
la tabla BGP (10.12.1.0/24 y 192.168.1.1/32). Las dos redes loopback de R2 (AS 65200) y R3
(AS 65300) se permiten porque están dentro de la primera entrada ACL-ALLOW, y dos
de las redes en el patrón 100.64.x.0 (100.64.2.0/25 y 100.64.3.0/25) se aceptan. La red
100.64.2.192/26 se rechaza porque la longitud del prefijo no
coincide con la segunda entrada ACL-ALLOW. El ejemplo 12-8 se puede consultar para
identificar las rutas antes de que se aplique la lista de distribución de BGP.
Ejemplo 12-10 Visualización de rutas filtradas por la lista de distribución BGP

*> 10. 12.1.0/240.0.0 .00 32768 ?
*> 1 0 0 .64.2.0/2510. 12.1.2220 65200 ?
*> 1 0 0 .64.3.0/2510. 12.1.2220 65200 65300 300 ?
*> 1 9 2 .168.1.1/320.0 .0.00 32768 ?
*> 1 9 2 .168.2.2/3210. 12.1.2220 65200 ?
*> 1 9 2 .168.3.3/3210. 12.1.233330 65200 65300 ?
Filtrado de listas de prefijos

Las listas de prefijos permiten filtrar los prefijos de red vecino por vecino, utilizando
una lista de prefijos. La configuración de una lista de prefijos implica el uso del comando
de configuración de la familia de direcciones BGP neighbor ip-address prefix-list prefix-
list-name {in | out}.
Para demostrar el uso de una lista de prefijos, podemos utilizar la misma tabla BGP
inicial del Ejemplo 12-8 y filtrarla para permitir sólo rutas dentro del espacio RFC 1918.
Se utiliza la misma lista de prefijos del Ejemplo 12-1 y se aplicará en el peering de R1 a R2
(AS 65200). El Ejemplo 12-11 muestra la configuración de la lista de prefijos y su
aplicación a R2.
Ejemplo 12-11 Configuración del filtrado de la lista de prefijos
R1# configurar terminal

Introduzca los comandos de configuración, uno por línea. Termine
con CNTL/Z. R1(config)# ip prefix-list RFC1918 seq 5 permit
192.168.0.0/13 ge 32 R1(config)# ip prefix-list RFC1918 seq 10 deny
0.0.0/0 ge 32 R1(config)# ip prefix-list RFC1918 seq 15 permit
10.0.0.0/7 ge 8 R1(config)# ip prefix-list RFC1918 seq 20 permit
172.16.0.0/11 ge 12 R1(config)# ip prefix-list RFC1918 seq 25
permit 192.168.0.0/15 ge 16 R1(config)# router bgp 65100
R1(config-router)# address-family ipv4 unicast
R1(config-router-af)# neighbor 10.12.1.2 prefix-list RFC1918 in
Ahora que se ha aplicado la lista de prefijos, se puede examinar la tabla BGP en R1, como se
muestra en el Ejemplo 12-12. Observe que las redes 100.64.2.0/25, 100.64.2.192/26 y
100.64.3.0/25 fueron filtradas ya que no estaban dentro de los criterios de coincidencia de la
lista de prefijos. El ejemplo 12-8 puede ser referenciado para identificar las rutas antes de que
se aplique la lista de prefijos BGP.
Ejemplo 12-12 Verificación del filtrado con una lista de prefijos BGP 12
*> 10. 3.3.0/2410. 12.1.2330 65200 65300 3003 ?
*10 .12.1.0/2410 .12.1. 2220 65200 ?
*> 0.0 .0.00 32768 ?
*> 10. 23.1.0/2410. 12.1.23330 65200 ?
*> 1 9 2 .168.1.1/320.0 .0.00 32768 ?
*> 1 9 2 .168.2.2/3210. 12.1.2220 65200 ?
*> 1 9 2 .168.3.3/3210. 12.1.233330 65200 65300 ?
Filtrado ACL de la ruta AS

La selección de rutas de un vecino BGP utilizando la ruta del AS requiere la definición
de una lista de control de acceso a la ruta del AS (AS path ACL). Las expresiones
regulares, introducidas anteriormente en este capítulo, son un componente del filtrado
AS_Path.
El ejemplo 12-13 muestra las rutas que R2 (AS 65200) anuncia hacia R1 (AS 65100).
Ejemplo 12-13 Configuración de la lista de acceso de la ruta AS
R2# show bgp ipv4 unicast neighbors 10.12.1.1 advertised-routes | begin Network
*> 10. 3.3.0/2410. 23.1.3330 65300 3003 ?
*> 10. 12.1.0/240.0.0 .00 32768 ?
*> 10. 23.1.0/240.0 .0.00 32768 ?
*> 1 0 0 .64.2.0/250.0 .0.00 32768 ?
*> 1 0 0 .64.2.192/26 0.0 .0.00 32768 ?
*> 1 0 0 .64.3.0/2510. 23.1.330 65300 300 ?
*> 1 9 2 .168.2.2/320.0 .0.00 32768 ?
*> 1 9 2 .168.3.3/3210. 23.1.33330 65300 ?
Número total de prefijos 8
R2 anuncia las rutas aprendidas de R3 (AS 65300) a R1. En esencia, R2 proporciona

conectividad de tránsito entre los sistemas autónomos. Si esto fuera una conexión a
Internet y R2 fuera una empresa, no querría anunciar las rutas aprendidas de otros AS.
Se recomienda utilizar una lista de acceso a la ruta del AS para restringir la publicidad
de sólo las rutas del AS 65200.
El procesamiento se realiza en un orden secuencial de arriba hacia abajo, y la primera
coincidencia calificada se realiza contra la acción de permiso o denegación apropiada.
Existe una denegación implícita al final de la ACL de ruta de AS. IOS admite hasta 500
ACL de ruta de AS y utiliza el comando ip as-path access-list acl-number {deny | permit}
regex-query para crear una ACL de ruta de AS. La ACL se aplica entonces con el comando
neighbor ip-address filter-list acl-number {in|out}.
El ejemplo 12-14 muestra la configuración en R2 utilizando una ACL de ruta de AS para
restringir el tráfico sólo al originado localmente, utilizando el patrón regex ^$ (consulte la
Tabla 12-5). Para garantizar la integridad, la ACL de ruta de AS se aplica a todas las
relaciones de vecindad de eBGP.
Ejemplo 12-14 Configuración de la lista de acceso de la ruta AS
R2
ip as-path access-list 1 permit ^$
!
router bgp 65200
address-family ipv4 unicast
neighbor 10.12.1.1 filter-list 1 out
vecino 10.23.1.3 filter-list 1 out
Ahora que la ACL de la ruta del AS ha sido aplicada, las rutas anunciadas pueden ser
revisadas de nuevo. El ejemplo 12-15 muestra las rutas anunciadas a R1. Observe que
todas las rutas no tienen una ruta AS, lo que confirma que sólo se anuncian externamente
las rutas de origen local. El Ejemplo 12-13 puede ser referenciado para identificar las
rutas antes de que se aplique la ACL de ruta AS de BGP.
Ejemplo 12-15 Verificación de anuncios de rutas locales con una ACL de ruta de AS
R2# show bgp ipv4 unicast neighbors 10.12.1.1 advertised-routes | begin Network
*> 10. 12.1.0/240.0.0 .00 32768 ?
*> 10. 23.1.0/240.0 .0.00 32768 ?
*> 1 0 0 .64.2.0/250.0 .0.00 32768 ?
*> 1 0 0 .64.2.192/26 0.0 .0.00 32768 ?
*> 1 9 2 .168.2.2/320.0 .0.00 32768 ?
Número total de prefijos 5
Mapas de rutas
Como se ha explicado anteriormente, los mapas de ruta proporcionan una funcionalidad
adicional sobre el filtrado puro. Los mapas de ruta proporcionan un método para manipular
los atributos de las rutas BGP. Los mapas de ruta se aplican en base a los vecinos de BGP para
las rutas que se anuncian o reciben. Un mapa de ruta diferente puede ser
utilizado para cada dirección. El mapa de ruta se asocia al vecino BGP con el comando
neighbor ip-address route-map route-map-name {in|out} bajo la familiade direcciones específica.
El ejemplo 12-16 muestra la tabla de enrutamiento BGP de R1, que se utiliza aquí para
demostrar el poder de un mapa de ruta.
Ejemplo 12-16 Tabla BGP antes de aplicar un mapa de ruta

*> 10. 1.1.0/240.0 .0.00 32768 ?
*> 10. 3.3.0/2410. 12.1.2330 65200 65300 3003 ?
*10 .12.1.0/2410 .12.1. 2220 65200 ?
*> 0.0 .0.00 32768 ?
*> 10. 23.1.0/2410. 12.1.23330 65200 ?
*> 1 0 0 .64.2.0/2510. 12.1.2220 65200 ?
*> 1 0 0 .64.2.192/26 10. 12.1.2220 65200 ?
*> 1 0 0 .64.3.0/2510. 12.1.2220 65200 65300 300 ? 12
*> 1 9 2 .168.1.1/320.0 .0.00 32768 ?
*> 1 9 2 .168.2.2/3210. 12.1.2220 65200 ?
*> 1 9 2 .168.3.3/3210. 12.1.233330 65200 65300 ?
Las hojas de ruta permiten también múltiples pasos en el procesamiento. Para demostrar este
concepto, nuestra hoja de ruta constará de cuatro pasos:
1. Denegar cualquier ruta que esté en la red 192.168.0.0/16 utilizando una lista de prefijos.
2. Coincidir con cualquier ruta originada en el AS 65200 que esté dentro del rango de
red 100.64.0.0/10 y establecer la preferencia local de BGP en 222.
3. Coincidir con cualquier ruta originada en el AS 65200 que no coincida con el
paso 2 y establecer el peso de BGP en 65200.
4. Permitir el procesamiento de todas las demás rutas.
El ejemplo 12-17 demuestra la configuración de R1, donde se referencian múltiples listas de
prefijos junto con una ACL de ruta de AS.
Ejemplo 12-17 Configuración del mapa de rutas de R1 para las rutas entrantes del AS 65200
R1
ip prefix-list FIRST-RFC1918 permit 192.168.0.0/15 ge
16 ip as-path access-list 1 permit _65200$
ip prefix-list SECOND-CGNAT permit 100.64.0.0/10 ge 11
!
route-map AS65200IN deny 10
description Denegar cualquier red RFC1918 a través de la
concordancia de la lista de prefijos match ip address prefix-
list FIRST-RFC1918
!
route-map AS65200IN permit 20
description Cambiar la preferencia local para AS65200 originar ruta en
100.64.x.x/10 match ip address prefix-list SECOND-CGNAT
match as-path 1
set local-preference 222
!
descripción Cambiar el peso de las rutas de origen de
AS65200 match as-path 1
peso del conjunto 65200
!
descripción Permitir todas las demás rutas sin modificar
!
router bgp 65100
neighbor 10.12.1.1 route-map AS65200IN in
El ejemplo 12-18 muestra la tabla de enrutamiento BGP de R1. Las siguientes acciones han ocurrido:
■ Las rutas 192.168.2.2/32 y 192.168.3.3/32 fueron descartadas. La ruta

192.168.1.1/32 es una ruta generada localmente.
■ A las redes 100.64.2.0/25 y 100.64.2.192/26 se les modificó la preferencia local a 222

porque se originaron en el AS 65200 y están dentro del rango de la red 100.64.0.0/10.
■ A las rutas 10.12.1.0/24 y 10.23.1.0/24 de R2 se les asignó el peso de atributo BGP

localmente significativo 65200.
■ Todas las demás rutas se recibieron y no se modificaron.
Ejemplo 12-18 Verificación de los cambios del mapa de rutas de R1 al AS 65200
R1# show bgp ipv4 unicast | b Red

*> 10. 1.1.0/240.0 .0.00 32768 ?
*> 10. 3.3.0/2410. 12.1.2330 65200 65300 3003 ?
r> 10. 12.1.0/2410. 12.1.222 65200 65200 ?
r0 .0.0. 00 32768 ?
*> 10. 23.1.0/2410. 12.1.2333 65200 65200 ?
*> 1 0 0 .64.2.0/2510. 12.1.222 2220
65200 ?
*> 1 0 0 .64.2.192/26 10. 12.1.222 2220 65200 ?
*> 1 0 0 .64.3.0/2510. 12.1.2220 65200 65300 300 ?
*> 1 9 2 .168.1.1/320.0 .0.00 32768 ?
NOTA Se considera una buena práctica utilizar una política de ruta diferente para los prefijos
entrantes y salientes para cada vecino BGP.
Borrar conexiones BGP

Dependiendo del cambio en la técnica de manipulación de rutas BGP, puede ser necesario
refrescar una sesión BGP para que tenga efecto. BGP soporta dos métodos para borrar una
sesión BGP. El primer método es un restablecimiento duro, que destruye la sesión BGP,
elimina las rutas BGP del peer, y es el más perjudicial. El segundo método es un reinicio
suave, que invalida la caché BGP y solicita un anuncio completo de su peer BGP.
Los routers inician un reinicio duro con el comando clear ip bgp ip-address [soft] y un
reinicio suave utilizando la palabra clave opcional soft. Todas las sesiones BGP de un
router pueden ser borradas usando un asterisco * en lugar de la dirección IP del peer.
Cuando una política BGP cambia, la tabla BGP debe ser procesada de nuevo para que los
vecinos puedan ser notificados en consecuencia. Las rutas recibidas por un peer BGP
deben ser procesadas de nuevo. Si la sesión BGP soporta la capacidad de refresco de rutas,
el peer vuelve a anunciar (refrescar) los prefijos al router solicitante, permitiendo que la
política de entrada se procese usando los nuevos cambios de política. La capacidad de
actualización de rutas se negocia para cada familia de direcciones cuando se establece la
sesión.
Al realizar un restablecimiento suave en sesiones que soportan la capacidad de refresco 12
de ruta, se inicia realmente un refresco de ruta. Los restablecimientos suaves se pueden
realizar para una familia de direcciones específica con la com-
mand clear bgp afi safi {ip-address|*} soft [in | out]. Los restablecimientos suaves reducen
el número de rutas que deben ser intercambiadas si se configuran múltiples familias de
direcciones con un solo peer BGP. Los cambios en las políticas de enrutamiento de salida
utilizan la palabra clave opcional out, y los cambios en las políticas de enrutamiento de
entrada utilizan la palabra clave opcional in. Se puede utilizar un * en lugar de especificar
la dirección IP de un peer para realizar esa acción para todos los peers BGP.
Comunidades BGP
Las comunidades BGP proporcionan una capacidad adicional para etiquetar rutas y para
modificar la política de enrutamiento BGP en los routers ascendentes y descendentes. Las
comunidades BGP pueden añadirse, eliminarse o modificarse selectivamente en cada
atributo a medida que una ruta viaja de un router a otro.
Las comunidades BGP son un atributo transitivo opcional de BGP que puede atravesar de
un AS a otro. Una comunidad BGP es un número de 32 bits que puede incluirse en una
ruta. Una comunidad BGP puede mostrarse como un número completo de 16 bits (0-
4.294.967.295) o como dos números de 16 bits (0-65535):(0-65535), comúnmente
conocido como nuevo formato.
Las comunidades BGP privadas siguen una convención particular en la que los primeros
16 bits representan el AS de origen de la comunidad, y los segundos 16 bits representan un
patrón definido por el AS de origen. Un patrón de comunidad BGP privada puede variar de
una organización a otra, no necesita ser registrado y puede significar ubicaciones geográficas
para un AS mientras que significa un método de publicidad de rutas en otro AS. Algunas
organizaciones publican sus patrones de comunidad BGP privada en sitios web como
http://www.onesc.net/communities/.
En 2006, el RFC 4360 amplió las capacidades de las comunidades BGP proporcionando un
formato extendido. Las comunidades BGP extendidas proporcionan una estructura para
varias clases de información y se utilizan comúnmente para los servicios VPN. El RFC
8092 proporciona soporte para comunidades mayores de 32 bits (que están fuera del
alcance de este libro).
Comunidades reconocidas
El RFC 1997 define un conjunto de comunidades globales (conocidas como
comunidades conocidas) que utilizan el rango de comunidades de 4.294.901.760
(0xFFFF0000) a 4.294.967.295 (0xFFFFFF).
Todos los routers capaces de enviar/recibir comunidades BGP deben implementar
comunidades conocidas. A continuación se muestran tres comunidades conocidas
comunes:
■ Internet: Se trata de una comunidad estandarizada para identificar las rutas

que deben anunciarse en Internet. En las redes más grandes que despliegan
BGP en el núcleo,
Las rutas anunciadas deben ser anunciadas a Internet y deben tener esta comunidad
establecida. Esto permite que los routers BGP de borde sólo permitan el anuncio de
rutas BGP con la comunidad de Internet a Internet. El filtrado no es automático, pero
puede hacerse con un mapa de rutas de salida.
■ No_Advertise: Las rutas con esta comunidad no deben anunciarse a ningún peer
BGP (iBGP o eBGP).
■ No_Export: Cuando se recibe una ruta con esta comunidad, la ruta no se anuncia a
ningún peer eBGP. Las rutas con esta comunidad pueden anunciarse a los pares
iBGP.
Habilitación del soporte comunitario de BGP
Los routers IOS e IOS XE no anuncian las comunidades BGP a los peers por defecto. Las
comunidades se habilitan vecino por vecino con el comando de configuración de la familia
de direcciones BGP neighbor ip-address send-community [standard | extended | both] bajo
la configuración de la familia de direcciones del vecino. Si no se especifica una palabra
clave, las comunidades estándar se envían por defecto.
Los nodos IOS XE pueden mostrar las comunidades en el nuevo formato, que es más fácil
de leer, con el comando de configuración global ip bgp-community new-format. El ejemplo
12-19 muestra la comunidad BGP en formato decimal primero, seguido del nuevo formato.
Ejemplo 12-19 Formatos de comunidad BGP
! Formato Decimal
R3# show bgp 192.168.1.1
! Salida omitida por brevedad
Entrada de la tabla de enrutamiento BGP para
192.168.1.1/32, versión 6 Comunidad: 6553602 6577023
! Nuevo formato
R3# show bgp 192.168.1.1
Entrada de la tabla de enrutamiento BGP para 192.168.1.1/32, versión 6
Comunidad: 100:2 100:23423
Comunidades BGP de coincidencia condicional

La coincidencia condicional de las comunidades BGP permite la selección de rutas basada en
las comunidades BGP dentro de los atributos de la ruta, de modo que se puede producir un
procesamiento selectivo en los mapas de ruta. El ejemplo 12-20 muestra la tabla BGP de R1,
que ha recibido múltiples rutas de R2 (AS 65200).
Ejemplo 12-20 Rutas BGP desde R2 (AS 65200)

*> 10. 1.1.0/240.0 .0.00 32768 ?
*10 .12.1.0/2410 .12.1. 2220 65200 ?
*> 0.0 .0.00 32768 ?
*> 10. 23.1.0/2410. 12.1.23330 65200 ?
*> 1 9 2 .168.1.1/320.0 .0.00 32768 ?
*> 1 9 2 .168.2.2/3210. 12.1.2220 65200 ?
*> 1 9 2 .168.3.3/3210. 12.1.233330 65200 65300 ?
En este ejemplo, digamos que se quiere hacer una coincidencia condicional para una
comunidad específica. Se puede mostrar toda la tabla BGP con el comando show bgp afi
safi detail y luego se puede seleccionar manualmente una ruta con una comunidad
específica. Sin embargo, si se conoce la comunidad BGP, se pueden mostrar todas las rutas
con el comando show bgp afi safi community, como se muestra en el Ejemplo 12-21.
Ejemplo 12-21 Visualización de las rutas BGP con una comunidad específica 12
R1# show bgp ipv4 unicast community 333:333 | begin Red
*> 10. 23.1.0/2410. 12.1.23330 65200 ?
El ejemplo 12-22 muestra la entrada de ruta explícita para la red 10.23.1.0/24 y todos los
atributos de la ruta BGP. Observe que dos comunidades BGP (333:333 y 65300:333) se
añaden a la ruta.
Ejemplo 12-22 Visualización de los atributos de la ruta BGP para la red 10.23.1.0/24
R1# show ip bgp 10.23.1.0/24

10.23.1.0/24, versión 15 Rutas: (1 disponible, mejor
#1, tabla por defecto)
No se anuncia a ningún
compañero Refrescar la
época 3
65200
10.12.1.2 desde 10.12.1.2 (192.168.2.2)
Origen incompleto, métrica 333, localpref 100, válido, externo, mejor
Comunidad: 333:333 65300:333
rx pathid: 0, tx pathid: 0x0
La concordancia condicional requiere la creación de una lista de comunidades que

comparte una estructura similar a la de una ACL, puede ser estándar o expandida, y
puede ser referenciada por número o nombre.
Las listas de comunidad estándar están numeradas del 1 al 99 y coinciden con
comunidades conocidas o con un número de comunidad privado (as-number:16-bit-number).
Las listas de comunidades ampliadas están numeradas del 100 al 500 y utilizan patrones
regex.
La sintaxis de configuración de una lista de comunidad es ip community-list {1-500 | standard
nombre-de-la-lista | nombre-de-la-lista-expandida} {permitir | negar} community-
pattern. Después de definir la lista de comunidades, se hace referencia a la lista de
comunidades en el mapa de rutas con el comando match community 1-500.
NOTA Cuando hay varias comunidades en la misma sentencia ip community list, todas las
comunidades para esa sentencia deben existir en la ruta. Si sólo se necesita una de las muchas
comunidades, puede utilizar varias declaraciones de lista de comunidades ip.
El ejemplo 12-23 demuestra la creación de una lista de comunidad BGP que coincide
con la comunidad 333:333. La lista de comunidad BGP se utiliza entonces en la primera
secuencia de
route-map COMMUNITY-CHECK, que niega cualquier ruta con esa comunidad. La
segunda secuencia del mapa de ruta permite todas las demás rutas BGP y establece el
peso BGP (localmente significativo) en 111. El mapa de ruta se aplica a las rutas
anunciadas desde R2 hacia R1.
Ejemplo 12-23 Coincidencia condicional de comunidades BGP
R1
ip community-list 100 permit 333:333
!
route-map COMMUNITY-CHECK deny 10
description Bloquear rutas con la comunidad 333:333
en ella match community 100
route-map COMMUNITY-CHECK permit 20
descripción Permitir rutas con cualquiera de las
comunidades en ella establecer el peso 111
!
router bgp 65100
neighbor 10.12.1.2 route-map COMMUNITY-CHECK in
El ejemplo 12-24 muestra la tabla BGP después de aplicar el mapa de ruta al vecino. El
prefijo de red 10.23.1.0/24 fue descartado, y todas las demás rutas aprendidas del AS
65200 tenían el peso BGP establecido en 111.
Ejemplo 12-24 Tabla BGP de R1 después de aplicar el mapa de rutas

*> 10. 1.1.0/240.0 .0.00 32768 ?
*10.12.1. 0/2410.12.1. 222 111 65200 ?
*> 0.0 .0.00 32768 ?
*> 1 9 2 .168.1.1/320.0 .0.00 32768 ?
*> 1 9 2 .168.2.2/3210. 12.1.222 111 65200 ?
*> 1 9 2 .168.3.3/3210. 12.1.23333 111 65200 65300 ?
Configuración de comunidades BGP privadas

Una comunidad BGP privada se establece en un mapa de ruta con el comando set
community bgp- community [additive]. Por defecto, cuando se establece una comunidad,
cualquier comunidad existente se sobreescribe, pero se puede preservar utilizando la
palabra clave opcional additive.
El ejemplo 12-25 muestra las entradas de la tabla BGP para la red 10.23.1.0/24, que tiene las
comunidades BGP 333:333 y 65300:333. La red 10.3.3.0/24 tiene la comunidad 65300:300.
Ejemplo 12-25 Visualización de las comunidades BGP para dos prefijos de red
R1# show bgp ipv4 unicast 10.23.1.0/24

65200
10.12.1.2 desde 10.12.1.2 (192.168.2.2)
Comunidad: 333:333 65300:333

Entrada de la tabla de enrutamiento BGP para 12
10.3.3.0/24, versión 12 65200 65300 3003
10.12.1.2 desde 10.12.1.2 (192.168.2.2)
Comunidad: 65300:300
El ejemplo 12-26 muestra la configuración en la que la comunidad BGP se establece en la

red 10.23.1.0/24. No se utiliza la palabra clave aditiva, por lo que los valores de comunidad
anteriores 333:333 y 65300:333 se sobrescriben con la comunidad 10:23. La red 10.3.3.0/24
tiene las comunidades 3:0, 3:3 y 10:10 añadidas a las comunidades existentes. El mapa de
rutas se asocia a R2 (AS 65200).
Ejemplo 12-26 Configuración de la comunidad BGP privada
ip prefix-list PREFIX10.23.1.0 seq 5 permit

10.23.1.0/24 ip prefix-list PREFIX10.3.3.0 seq 5 permit
10.3.3.0/24
!
route-map SET-COMMUNITY permit 10
match ip address prefix-list PREFIX10.23.1.0
set community 10:23
match ip address prefix-list PREFIX10.3.3.0
set community 3:0 3:3 10:10 additive
!
router bgp 65100
address-family
ipv4
neighbor 10.12.1.2 route-map SET-COMMUNITY in
Ahora que se ha aplicado el mapa de ruta y se han refrescado las rutas, se pueden examinar los
atributos de la ruta, como se demuestra en el Ejemplo 12-27. Como se anticipó, las
comunicaciones BGP anteriores se eliminaron para la red 10.23.1.0/24 pero se mantuvieron para
la red 10.3.3.0/24.
Ejemplo 12-27 Verificación de cambios de comunidad BGP

65200
10.12.1.2 desde 10.12.1.2 (192.168.2.2)
Comunidad: 10:23
10.3.3.0/24, versión 20 65200 65300 3003
10.12.1.2 desde 10.12.1.2 (192.168.2.2)
Comunidad: 3:0 3:3 10:10 65300:300
Comprensión de la selección de la ruta BGP
El algoritmo de selección de la mejor ruta de BGP influye en cómo el tráfico entra o sale de un AS.
Algunas configuraciones de routers modifican los atributos de BGP para influir en el tráfico
entrante, en el tráfico saliente o en el tráfico entrante y saliente, dependiendo de los requisitos de
diseño de la red. Muchos ingenieros de redes no entienden la selección de la mejor ruta de BGP, lo
que a menudo puede resultar en un enrutamiento subóptimo. Esta sección explica la lógica
utilizada por un router que utiliza BGP cuando reenvía paquetes.
Selección de la ruta de encaminamiento mediante la coincidencia más larga

Los routers siempre seleccionan la ruta que debe tomar un paquete examinando la longitud
del prefijo de una entrada de red. La ruta seleccionada para un paquete se elige en base a la
longitud del prefijo, donde siempre se prefiere la longitud de prefijo más larga. Por ejemplo,
se prefiere /28 sobre /26, y /26 sobre /24.
Esta lógica puede utilizarse para influir en la selección de rutas en BGP. Supongamos que
una organización posee el rango de red 100.64.0.0/16 pero sólo necesita anunciar dos
subredes (100.64.1.0/24 y 100.64.2.0/24). Podría anunciar ambos prefijos (100.64.1.0/24 y
100.64.2.0/24) desde todos los
sus routers, pero ¿cómo puede distribuir la carga para cada subred si todo el tráfico entra
en un router (como R1)?
La organización podría modificar varios atributos de ruta (PAs) de BGP que se anuncian
externamente, pero un SP podría tener una política de enrutamiento BGP que ignora esos
atributos de ruta, resultando en la recepción aleatoria de tráfico de red.
Una forma más elegante que garantiza que las rutas se seleccionan de forma determinista
fuera de la organización es anunciar un prefijo resumen (100.64.0.0/16) en ambos routers.
Entonces la organización puede anunciar un prefijo más largo que coincida con el router que
debe recibir el tráfico de red para ese prefijo. La Figura 12-10 muestra el concepto, con el R1
anunciando el prefijo 100.64.1.0/24, el R2 anunciando el prefijo 100.64.2.0/24, y ambos routers
anunciando el prefijo de red de resumen 100.64.0.0/16.
Internet
AS100 AS200
R1 R2
Red empresarial
100.64.1.0/24
100.64.2.0/24
100.64.0.0/16
100.64.1.0/24
100.64.0.0/16
100.64.0.0/16
100.64.2.0/24
Figura 12-10 Selección de la ruta BGP utilizando la coincidencia más larga
Independientemente de la política de enrutamiento de un SP, los prefijos más específicos 12
se anuncian en un solo router. La redundancia se consigue anunciando la dirección de
resumen. Si el R1 falla, los dispositivos utilizan el anuncio de ruta del R2 de 100.64.0.016
para alcanzar la red 100.64.1.0/24.
NOTA Asegúrese de que los resúmenes de red que se anuncian desde su organización están
dentro de su rango de red. Además, los proveedores de servicios no suelen aceptar rutas IPv4
más largas que /24 (por ejemplo, /25 o /26) o rutas IPv6 más largas que /48. Las rutas se
restringen para controlar el tamaño de la tabla de enrutamiento de Internet.
Visión general de la mejor ruta de BGP

En BGP, los anuncios de ruta consisten en información de alcanzabilidad de la capa de red
(NLRI) y atributos de ruta (PA). El NLRI consiste en el prefijo de red y la longitud del
prefijo, y los atributos BGP como AS_Path, origen, etc. se almacenan en los PAs. Una ruta
BGP puede contener múltiples caminos hacia la misma red de destino. Los atributos de
cada ruta afectan a la conveniencia de la ruta cuando un router selecciona la mejor ruta. Un
router BGP anuncia sólo la mejor ruta a los routers vecinos.
Dentro de la tabla BGP Loc-RIB, se mantienen todas las rutas y sus atributos de ruta con la
mejor ruta calculada. La mejor ruta se instala entonces en la RIB del router. Si la mejor ruta
ya no está disponible, el router puede utilizar las rutas existentes para identificar
rápidamente una nueva mejor ruta. BGP recalcula la mejor ruta para un prefijo ante cuatro
posibles eventos:
■ Cambio de accesibilidad del siguiente salto de BGP
■ Fallo de una interfaz conectada a un peer eBGP
■ Cambio en la redistribución
■ Recepción de caminos nuevos o eliminados para una ruta
BGP instala automáticamente la primera ruta recibida como la mejor ruta. Cuando se
reciben rutas adicionales para la misma longitud de prefijo de red, las nuevas rutas se
comparan con la mejor ruta actual. Si hay un empate, el proceso continúa hasta que se
identifica un ganador de la mejor ruta.
El algoritmo de mejor ruta de BGP utiliza los siguientes atributos, en el orden
indicado, para la selección de la mejor ruta:
1. Peso
2. Preferencia local
3. Originado localmente (declaración de red, redistribución o agregación)
4. AIGP
5. Ruta AS más corta
6. Tipo de origen
7. MED más bajo
8. eBGP sobre iBGP
9. Salto siguiente IGP más bajo
10. Si ambas rutas son externas (eBGP), prefiere la primera (la más antigua)
11. Prefiere la ruta que proviene del peer BGP con el RID más bajo
12. Prefiere la ruta con la longitud mínima de la lista de clústeres
13. Prefiere la ruta que proviene de la dirección vecina más baja
La política de enrutamiento BGP puede variar de una organización a otra, basándose en
la manipulación de los PAs BGP. Debido a que algunos PAs son transitivos y llevan de
un AS a otro AS, esos cambios podrían impactar el enrutamiento descendente para otros
SPs, también. Otros PAs son no transitivos y sólo influyen en la política de enrutamiento
dentro de la organización. Red
Los prefijos se emparejan condicionalmente en función de una serie de factores, como la
longitud de la AS_Path, el ASN específico, las comunidades BGP u otros atributos.
El algoritmo de la mejor ruta se explica en las siguientes secciones.
Peso
El peso de BGP es un atributo definido por Cisco y el primer paso para seleccionar la mejor
ruta de BGP. El peso es un valor de 16 bits (0 a 65.535) asignado localmente en el router; no
se anuncia a otros routers. Se prefiere la ruta con mayor peso. El peso puede establecerse
para rutas específicas con un mapa de ruta de entrada o para todas las rutas aprendidas de
un vecino específico. El peso no se anuncia a los pares y sólo influye en el tráfico de salida
de un router o de un AS. Debido a que es el primer paso en el algoritmo de la mejor ruta,
debe ser utilizado cuando otros atributos no deben influir en la mejor ruta para una red
específica.
El ejemplo 12-28 muestra la tabla BGP para el prefijo de red 172.16.1.0/24 en R2. En la
tercera línea de la salida, el enrutador indica que existen dos rutas y que la primera es la
mejor. Al examinar la salida de cada ruta, la ruta aprendida a través del AS 65300 tiene
un peso de 123. La ruta a través del AS 65100 no tiene el peso, lo que equivale a un valor
de 0; por lo tanto, la ruta a través del AS 65300 es la mejor ruta.
Ejemplo 12-28 Ejemplo de elección de la mejor ruta BGP basada en el peso

172.16.1.0/24, versión 3 Rutas: (2 disponibles, mejor
Refrescar la época 2
65300
10.23.1.3 desde 10.23.1.3 (192.18.3.3)
Origen IGP, métrica 0, localpref 100, peso 123, válido, externo, best
Refresh Epoch 2
65100
10.12.1.1 desde 10.12.1.1 (192.168.1.1)
Origen IGP, métrica 0, localpref 100, válido, externo
Preferencia local
La preferencia local (LOCAL_PREF) es un atributo de ruta discrecional bien conocido y
se incluye en los anuncios de ruta en todo un AS. El atributo de preferencia local es un
32- valor de bits (0 a 4.294.967.295) que indica la preferencia de salida del AS hacia la red
de destino. La preferencia local no se anuncia entre pares eBGP y se suele utilizar para
influir en la dirección del siguiente salto para el tráfico de salida (es decir, para salir de un
sistema autónomo). La preferencia local puede establecerse para rutas específicas
utilizando un mapa de ruta o para todas las rutas recibidas de un vecino específico.
Un valor más alto se prefiere sobre un valor más bajo. Si un router BGP de borde no define 12
la preferencia local al recibir un prefijo, el valor de preferencia local por defecto de 100 se
utiliza durante el cálculo de la mejor ruta, y se incluye en los anuncios a otros peers iBGP.
La modificación de la preferencia local puede influir en la selección de la ruta en otros
peers iBGP sin afectar a los peers eBGP porque la preferencia local no se anuncia fuera del
sistema autónomo.
El ejemplo 12-29 muestra la tabla BGP para el prefijo de red 172.16.1.0/24 en R2. En la
tercera línea de la salida, el enrutador indica que existen dos rutas, y la primera es la mejor
ruta. El peso BGP no existe, por lo que se utiliza la preferencia local. La ruta aprendida a
través del AS 65300 es la mejor ruta porque tiene una preferencia local de 333, mientras
que la ruta a través del AS 65200 tiene una preferencia local de 111.
Ejemplo 12-29 Ejemplo de elección de la mejor ruta BGP basada en la preferencia local

Anunciado a los grupos de
actualización: 2
Actualizar la época 4
65300
10.23.1.3 desde 10.23.1.3 (192.18.3.3)
Origen IGP, métrica 0, localpref 333, válido, externo, best
Refresh Epoch 4
65100
10.12.1.1 desde 10.12.1.1 (192.168.1.1)
Originado localmente a través de la red o la publicidad agregada

El tercer punto de decisión en el algoritmo de la mejor ruta es determinar si la ruta
se origina localmente. La preferencia se da en el siguiente orden:
■ Rutas que se anunciaron a nivel local
■ Redes que han sido agregadas localmente
■ Rutas recibidas por los peers de BGP
Protocolo de Pasarela Interior Acumulado

El Protocolo Acumulado de Pasarela Interior (AIGP) es un atributo opcional de ruta no
transitiva que se incluye en los anuncios a través de un AS. Los IGP suelen utilizar la
métrica del camino más bajo para identificar el camino más corto a un destino, pero no
pueden proporcionar la escalabilidad de BGP. BGP utiliza un AS para identificar un único
dominio de control para una política de enrutamiento. BGP no utiliza la métrica del camino
debido a problemas de escalabilidad combinados con la noción de que cada AS puede
utilizar una política de enrutamiento diferente para calcular las métricas.
AIGP ofrece la posibilidad de que BGP mantenga y calcule una métrica de ruta conceptual
en entornos que utilizan múltiples AS con dominios de enrutamiento IGP únicos en cada
AS. La capacidad de BGP de tomar decisiones de enrutamiento basadas en una métrica de
ruta es una opción viable porque todos los AS están bajo el control de un único dominio,
con políticas de enrutamiento consistentes para BGP e IGP.
En la Figura 12-11, el AS 100, el AS 200 y el AS 300 están todos bajo el control del mismo
proveedor de servicios. Se ha habilitado AIGP en las sesiones BGP entre todos los routers, y los
IGPs se redistribuyen en BGP. La métrica AIGP se anuncia entre el AS 100, el AS 200 y el AS
300, lo que permite a BGP utilizar la métrica AIGP para calcular la mejor ruta entre los sistemas
autónomos.
AS100
AS200 AS300
IGP 1
IGP 2 IGP 3
R1 R3 R4 R6
R2 R5 R7
Métricas de la ruta
Métricas de la ruta AIGP a R1 y Métricas de la ruta AIGP a R6 y
AIGP a R3, R4, R5, R6
R2 R7
y R7
Métricas de la ruta
AIGP a R1, R2, R3, R4
y R5
Figura 12-11 Intercambio de atributos de ruta AIGP entre sistemas autónomos
Las siguientes directrices se aplican a las métricas de la AIGP:
■ Una ruta con una métrica AIGP es preferible a una ruta sin métrica AIGP.
■ Si la dirección del siguiente salto requiere una búsqueda recursiva, la ruta AIGP
necesita calcular una métrica derivada para incluir la distancia a la dirección del
siguiente salto. Esto garantiza que se incluya el coste hasta el enrutador de borde
BGP. La fórmula es
Métrica AIGP derivada = (métrica AIGP original + métrica AIGRP del siguiente salto)
■ Si existen varias rutas AIGP y una dirección de siguiente salto contiene una
métrica AIGP y la otra no, no se utiliza la ruta no AIGP.
■ La métrica AIGP del siguiente salto se añade recursivamente si se realizan varias búsquedas.
■ Las rutas AIGP se comparan basándose en la métrica AIGP derivada (con saltos
siguientes recursivos) o en la métrica AIGP real (salto siguiente no recursivo). Se
prefiere la ruta con la métrica AIGP más baja.
■ Cuando un router R2 anuncia una ruta habilitada para AIGP que se aprendió del
R1, si la dirección del siguiente salto cambia a una dirección de R2, R2 incrementa
la métrica AIGP para reflejar la distancia (la métrica de la ruta IGP) entre R1 y R2.
Ruta de AS más corta

El siguiente factor de decisión para el algoritmo de mejor ruta de BGP es la longitud de la
ruta del AS. La longitud de la ruta suele estar relacionada con el número de saltos del AS.
Una ruta de AS más corta es preferible a una ruta de AS más larga.
Al anteponer ASN a la ruta del AS, ésta se alarga, lo que hace que esa ruta sea menos 12
deseable en comparación con otras. Normalmente, a la ruta del AS se le añade el ASN del
propietario de la red.
En general, una ruta a la que se le ha añadido la ruta del AS no se selecciona como la
mejor ruta de BGP porque la ruta del AS es más larga que el anuncio de la ruta no
prepagada. El tráfico entrante se ve influenciado por la longitud de la ruta del AS
prependida en los anuncios a otros ASs, y el tráfico saliente se ve influenciado por los
anuncios prependidos recibidos de otros ASs.
El Ejemplo 12-30 muestra la tabla BGP para el prefijo de red 172.16.1.0/24 en R2. La
segunda ruta aprendida a través del AS 65100 es la mejor ruta. No hay un peso establecido
en ninguna de las rutas, y la preferencia local es idéntica. La segunda ruta tiene una
longitud de ruta de AS de 1, mientras que la primera ruta tiene una longitud de ruta de AS
de 2 (65300 y 65300).
Ejemplo 12-30 Ejemplo de elección de la mejor ruta de BGP basada en la longitud de la ruta del AS

actualización: 2
65300 65300
10.23.1.3 desde 10.23.1.3 (192.18.3.3)
Refresh Epoch 8
65100
10.12.1.1 desde 10.12.1.1 (192.168.1.1)
Origen IGP, métrica 0, localpref 100, válido, externo, mejor
NOTA Los ASN se repiten en la primera entrada, lo que indica que el AS 65300 preanunció su
anuncio BGP para dirigir el tráfico de la red.
NOTA El peering con diferentes proveedores de Internet proporciona un enrutamiento óptimo

a la mayoría de las empresas, ya que un SP puede estar a un salto de la ruta de AS (o
proporcionar conectividad a otros SP de nivel 2/3), mientras que otro SP puede tener una ruta
de AS más corta para otros clientes.
Tipo de origen
El siguiente factor de decisión de la mejor ruta de BGP es el conocido atributo obligatorio
de BGP llamado origen. Por defecto, las redes que se anuncian a través de la declaración
de red se establecen con el origen IGP o i, y a las redes redistribuidas se les asigna el
atributo de origen Incompleto o ? El orden de preferencia del origen es
1. Origen del IGP (la mayoría)

2. Origen del EGP
3. Origen incompleto (mínimo)
El ejemplo 12-31 muestra la tabla BGP para el prefijo de red 172.16.1.0/24 en R2. La segunda
ruta aprendida a través del AS 65100 es la mejor ruta porque tiene un origen de IGP,
mientras que la primera ruta tiene un origen incompleto, que es el menos preferido.
Ejemplo 12-31 Ejemplo de elección de la mejor ruta BGP basada en el tipo de origen

actualización: 2
65300
10.23.1.3 desde 10.23.1.3 (192.18.3.3)
Origen incompleto, métrica 0, localpref 100, válido, externo
Refresh Epoch 10
65100
10.12.1.1 desde 10.12.1.1 (192.168.1.1)
Origen IGP, métrica 0, localpref 100, válido, externo, mejor
Discriminador de salida múltiple

El siguiente factor de decisión de la mejor ruta de BGP es el atributo no transitivo de BGP
denominado discriminador de salida múltiple (MED). El MED utiliza un valor de 32 bits
(de 0 a 4.294.967.295) llamado métrica. BGP establece el MED automáticamente a la
métrica de la ruta IGP durante la publicidad o redistribución de la red. Si el MED se
recibe de una sesión de eBGP, puede anunciarse a otros peers de iBGP, pero no debe
enviarse fuera del AS que lo recibió.
El propósito de MED es influir en los flujos de tráfico entrante desde un AS diferente. Un
MED más bajo es preferible a un MED más alto.
NOTA Para que MED sea un factor de decisión eficaz, los trayectos sobre los que se decide
deben proceder del mismo ASN.
Las directrices del RFC 4451 establecen que un prefijo sin valor MED debe tener prioridad
y, en esencia, debe compararse con un valor 0. Algunas organizaciones exigen que se
establezca un MED con un valor específico para todos los prefijos y declaran que las rutas
sin el MED deben
se tratará como la menos preferida. Por defecto, si falta el MED de un prefijo aprendido de
un peer eBGP, los dispositivos utilizan un MED de 0 para el cálculo de la mejor ruta. Los
routers IOS anuncian un MED de 0 a los peers iBGP.
El Ejemplo 12-32 muestra la tabla BGP para el prefijo de red 172.16.1.0/24 en el R2.
Obsérvese que el R2 está haciendo peering sólo con el AS 65300 para que MED sea
elegible para la selección de la mejor ruta
proceso. El primer camino tiene un MED de 0, y el segundo camino tiene un MED de 33. Se
prefiere el primer camino porque el MED es menor.
Ejemplo 12-32 Ejemplo de elección de la mejor ruta BGP basada en MED 12
R2# show bgp ipv4 unicast 172.16.1.0
actualización: 2
65300
10.12.1.1 desde 10.12.1.1 (192.168.1.1)
Origen IGP, métrica 0, localpref 100, válido, externo, best
Refresh Epoch 14
65300
10.23.1.3 desde 10.23.1.3 (192.18.3.3)
NOTA Es posible que el SP se olvide de anunciar el MED de ambos peers y configure sólo
uno. Esto podría tener consecuencias no deseadas y se puede solucionar fácilmente.
eBGP sobre iBGP

El siguiente factor de decisión de la mejor ruta BGP es si la ruta proviene de un peering
iBGP, eBGP o de un AS miembro de la confederación (sub-AS). El orden de selección de la
mejor ruta es
1. Pares eBGP (lo más deseable)

2. Miembro de la Confederación AS pares
3. Peers iBGP (menos deseable)
NOTA Las confederaciones BGP están fuera del alcance del examen CCNP y CCIE Enterprise
Core ENCOR 350-401 y no se tratan en este libro.
Métrica IGP más baja

El siguiente paso de decisión es utilizar el costo IGP más bajo para la dirección del siguiente
salto de BGP. La Figura 12-12 ilustra una topología en la que R2, R3, R4 y R5 están en el AS
400. El AS 400 se agrupa en una malla completa y establece sesiones BGP utilizando las
interfaces Loopback 0. R1 anuncia el prefijo de red 172.16.0.0/24 a R2 y R4.
R3 prefiere la ruta desde R2 en comparación con la ruta iBGP desde R4 porque la métrica
para llegar a la dirección del siguiente salto es menor. El R5 prefiere la ruta desde el R4 en
comparación con la ruta iBGP desde el R2 porque la métrica para alcanzar la dirección del
siguiente salto es menor.
Red Next- Métri Red Next- Métri
Hop
*> 172.16.0.0/24 10.1.12.1 Hop
*>i 172.16.0.0/24 192.168.2.2
ca 1 ca 10
* 192.168.4.4 10 * 192.168.4.4 20
i i
10.1.23.0/2
10.1.12.
R2 4 R3
0/24
172.16.0.0/24
172.16.0.0/2
10.24.1.0/24
10.1.35.0/24
4
AS400
R1
AS10
0 10.1.14.
0/24 172.16.0.0/24
R4 10.1.45.0/2 R5
4
Red Next- Métri Red Next- Métri
Hop
* i 172.16.0.0/24 192.168.2.2 Hop
* i 172.16.0.0/24 192.168.2.2
ca 10 ca 20
*>
10.1.14.1 1 *> 192.168.4.4 10
i i
Figura 12-12 Topología de la métrica IGP más baja

Preferir la ruta eBGP más antigua
BGP puede mantener grandes tablas de enrutamiento, y las sesiones inestables hacen que
el cálculo de la mejor ruta de BGP se ejecute con frecuencia. BGP mantiene la estabilidad en
una red prefiriendo la ruta de la sesión BGP más antigua (establecida).
La desventaja de esta técnica es que no conduce a un método determinista para identificar la
mejor ruta BGP desde una perspectiva de diseño.
ID del router
El siguiente paso del algoritmo de mejor ruta de BGP es seleccionar la mejor ruta
utilizando el ID de enrutador más bajo del enrutador eBGP anunciante. Si la ruta fue
recibida por un reflector de ruta, entonces el ID del originador es sustituido por el ID del
enrutador.
Longitud mínima de la lista de racimos

El siguiente paso en el algoritmo de mejor ruta de BGP es seleccionar la mejor ruta
utilizando la menor longitud de la lista de clústeres. La lista de clústeres es un atributo
BGP no transitivo que se añade (no se sobrescribe) por un reflector de ruta con su ID de
clúster. Los reflectores de ruta utilizan el atributo de ID de clúster como mecanismo de
prevención de bucles. El ID de cluster no se anuncia entre ASs y es localmente
significativo. En términos más sencillos, este paso localiza la ruta que ha recorrido el
menor número de saltos publicitarios iBGP.
NOTA Los reflectores de ruta BGP están fuera del alcance del examen CCNP y CCIE
Enterprise Core ENCOR 350-401 y no se tratan en este libro.
Dirección del vecino más bajo

El último paso del algoritmo de mejor ruta de BGP consiste en seleccionar la ruta que proviene del menor
12
Dirección del vecino BGP. Este paso se limita a los peerings iBGP porque los peerings
eBGP utilizan la ruta más antigua recibida como desempate.
La Figura 12-13 demuestra el concepto de elegir el router con la dirección vecina más baja.
R1 está anunciando el prefijo de red 172.16.0.0/24 a R2. R1 y R2 han establecido dos
sesiones BGP utilizando las redes 10.12.1.0/24 y 10.12.2.0/24. R2 selecciona la ruta
anunciada desde 10.12.1.1 por ser la dirección IP más baja.
172.16.0.0/24
172.16.0.0/24 Originador: 10.12.1.1
10.12.1.0/24
.1 AS100 .2
R1R2
10.12.2.0/24
172.16.0.0/24 Originador: 10.12.2.1
Figura 12-13 Dirección IP más baja
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 12-9 enumera estos temas clave y el número de
página en el que se encuentra cada uno.
Tabla 12-9 Temas clave del capítulo 12

Elemento temático Descripción Página
clave
Sección Resiliencia en los proveedores de servicios 287
Sección Enrutamiento de tránsito en Internet 288
Sección Selección de red IGP ACL ampliada 292
Sección Selección de red BGP ACL ampliada 292
Párrafo Especificaciones de coincidencia de prefijos 293
Párrafo Coincidencia de prefijos con parámetros de 293
longitud
Sección Listas de prefijos 295
Sección Expresiones regulares 296
Lista Componentes del mapa de ruta 297
Lista Sintaxis y tratamiento de la hoja de ruta 297
Sección Correspondencia condicional del mapa de 298
ruta
Elemento temático Descripción Página
clave
Sección Coincidencia de mapas de ruta con múltiples 299
condiciones
Sección Acciones opcionales de la hoja de ruta 300
Sección Filtrado de listas de distribución BGP 303
Sección Filtrado de listas de prefijos BGP 304
Párrafo ACL de la ruta del AS de BGP 305
Sección Mapas de ruta BGP para los vecinos 306
Sección Comunidades BGP 309
Sección Habilitación del soporte de la comunidad 310
BGP
Párrafo Lista de comunidades BGP 311
Sección Configuración de comunidades BGP 312
privadas
Sección Selección de la ruta de encaminamiento 314
mediante la coincidencia más larga
Lista Algoritmo de mejor ruta de BGP 315
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:
Lista de control de acceso (ACL) de la ruta AS, comunidad BGP, multihoming BGP,
lista de distribución, lista de prefijos, expresión regular (regex), mapa de ruta,
enrutamiento de tránsito
Utilice la referencia de comandos para comprobar su memoria

La Tabla 12-10 enumera los comandos importantes de este capítulo. Para probar su
memoria, cubra el lado derecho de la tabla con un papel, lea la descripción en el lado
izquierdo y vea cuánto del comando puede recordar.
Tabla 12-10 Referencia de comandos

Tarea Sintaxis del comando
Configurar una lista de prefijos {ip | ipv6} prefix-list prefix-list-name [seq
sequence-number] {permit | deny} high-
order- bit-pattern/high-order-bit-count [ge
ge-value] [le le-value]
Crear una entrada en la hoja de ruta route-map route-map-name [permit |
deny] [sequence-number]
Coincidencia condicional en un match as-path acl-number
mapa de rutas utilizando la ruta
del AS
Coincidencia condicional en un match ip address {acl-number | acl-name}
mapa de rutas mediante una ACL
Coincidencia condicional en un match ip address prefix-list prefix-list-name
mapa de rutas utilizando una lista
de prefijos
12
Tarea Sintaxis del comando

Coincidencia condicional en una match local-preference local-preference
hoja de ruta utilizando una
preferencia local
Filtrar las rutas hacia un vecino BGP neighbor ip-address distribute-list {acl-number |
mediante una ACL acl-name} {in|out}
Filtrar las rutas hacia un vecino BGP neighbor ip-address prefix-list prefix-list-name
mediante una lista de prefijos {en | fuera}
Crear una ACL basada en la ruta ip as-path access-list acl-number {deny | permit}
del AS de BGP consulta regex
Filtrar las rutas hacia un vecino BGP neighbor ip-address filter-list acl-number {in|
utilizando una ACL de ruta de AS out}
Asociar una hoja de ruta de entrada o neighbor ip-address route-map route-map-
salida con un vecino BGP específico name
{in|out}
Configurar los routers basados en ip bgp-community new-format
IOS para mostrar la comunidad en
un nuevo formato para facilitar la
lectura de las comunidades BGP
Crear una lista de ip community-list {1-500 | nombre de la
comunidad BGP para la lista estándar | nombre de la lista
coincidencia de rutas expandida} {permitir | denegar}
condicional community-pattern
Establecer comunidades BGP en un set community bgp-community [additive]
mapa de rutas
Iniciar una actualización de rutas clear bgp afi safi {direcciónip|*} soft [in | out].
para un peer BGP específico
Muestra la tabla BGP actual, basada show bgp afi safi regexp regex-pattern
en las rutas que cumplen con un
patrón regex de ruta de AS
especificado
Muestra la tabla BGP actual, show bgp afi safi community
basada en las rutas que cumplen
con una comunidad BGP
especificada
Referencias en este capítulo

RFC 4360, BGP Extended Communities Attribute, por
Yakov Rekhter, Dan Tappan y Srihari R. Sangli.
https://www.ietf.org/rfc/rfc4360.txt, febrero de 2006.
RFC 8092, BGP Large Communities Attribute, por John Heasley, et. al. https://www.ietf.org/rfc/rfc2858.txt,
febrero de 2017.

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

Cargado por

Copyright:

Formatos disponibles

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

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

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

Cargado por

Copyright:

Formatos disponibles

CAPÍTULO 12

Este capítulo abarca los siguientes temas:

Filtrado y flanqueo de rutas BGP: Esta sección amplía el funcionamiento de la

Comunidades BGP: En esta sección se explica el atributo de ruta obligatoria conocida

"¿Ya sé esto?" Cuestionario

1. El enrutamiento en tránsito entre una red empresarial multihomed y un proveedor

Resiliencia en los proveedores de servicios

■ Escenario 2: R1 se conecta a R3 y R4 con el mismo SP. Este diseño tiene en cuenta

■ Escenario 3: R1 se conecta a R3 y R4 con los diferentes SPs. Este diseño tiene en

■ Escenario 4: R1 y R2 forman una sesión iBGP entre ellos. R3 se conecta a SP1, y R4 se

Enrutamiento de tránsito por Internet

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

Rutas de tránsito de las sucursales

Enrutamiento determinista durante la conmutación por error

Sitio 3 Redes Sitio 4 Redes Sitio 5 Redes

Figura 12-3 Enrutamiento determinista

Sitio 3 Redes Sitio 4 Redes Sitio 5 Redes

Figura 12-4 Enrutamiento no determinista durante la conmutación por error

■ Los circuitos del router de tránsito pueden saturarse porque fueron

■ Los patrones de enrutamiento pueden volverse impredecibles y no deterministas. En

■ Un diseño adecuado de las rutas puede dar cabida a las interrupciones.

■ El ancho de banda se puede dimensionar en consecuencia.

■ El patrón de enrutamiento es bidireccional y predecible.

NOTA El enrutamiento de tránsito en el centro de datos u otras ubicaciones planificadas es

Listas de control de acceso

Las ACL se clasifican en dos categorías:

■ ACLs estándar: Definen los paquetes basándose únicamente en la red de origen.

Paso 1. Defina la ACL mediante el comando ip access-list standard {acl-number |

Paso 1. Defina la ACL mediante el comando ip access-list extended {acl-number |

Selección de la red IGP

Tabla 12-3 ACL ampliada para la selección de rutas IGP

Selección de red BGP

permit protocol source source-wildcard destination destination-wildcard

Coincide con las redes Coincide con la máscara de la red

Prefijo: 192.168.0.0/16 11000000 00000000 1

■ le: Menor o igual que, <=

■ ge: Mayor o igual que, >=

Prefijo: 10.168.0.0/13 000010 101 0 000000 00000000 1

Patrón de bits de Parámetros de

Prefijo: 10.0.0.0/8 000010 00000000 00000000 00000000 8

recuento de bits de alto orden < valor ge <= valor le

ip prefix-list RFC1918 seq 5 permit 192.168.0.0/13 ge

Listas de prefijos IPv6

ipv6 prefix-list PRIVATE-IPV6 seq 5 permit 2001:2::/48 ge 48

Expresiones regulares (regex)

Tabla 12-5 Modificadores de consulta RegEx

Tabla 12-6 Expresiones regulares comunes de BGP

■ Número de secuencia: Dicta el orden de procesamiento de la hoja de ruta.

■ Criterios de coincidencia condicional: Identifica las características del prefijo (red,

■ Acción de procesamiento: Permite o deniega el prefijo.

■ Acción opcional: Permite realizar manipulaciones, dependiendo de cómo se

Un mapa de ruta utiliza la sintaxis del comando route-map route-map-name

■ Si no se proporciona una acción de procesamiento, se utiliza el valor por defecto permiso.

■ Si no se proporciona un número de secuencia, el número de secuencia se

■ Si no se incluye una sentencia que coincida, se asocia un prefijo implícito a la

■ El procesamiento dentro de una hoja de ruta se detiene después de que se

route-map EXAMPLE permit 10

route-map EXAMPLE deny 20