Estudios de casos de BGP

Estudios de casos de BGP
Contenidos
Introducción
Requisitos previos
Requisitos
Componentes utilizados
Convenciones
Estudios de casos de BGP 1
¿Cómo funciona BGP?
eBGP e iBGP
Habilitación del enrutamiento BGP
Formación de vecinos BGP
BGP y las interfaces de bucle de retorno
eBGP de varios saltos
eBGP de varios saltos (balance de carga)
Correspondencias de la ruta
Comandos de configuración match y set
El comando network
Redistribución
Rutas estáticas y redistribución
iBGP
El algoritmo de decisión BGP
Estudios de casos de BGP 2
Atributo AS_PATH
Atributo de origen
Atributo de salto siguiente de BGP
Entrada posterior de BGP
Sincronización
Atributo de peso
Atributo de preferencia local
Atributo de métrica
Atributo de comunidad
Estudios de casos de BGP 3
Filtrado de BGP
Expresión normal de AS
Vecinos y correspondencias de la ruta BGP
Estudios de casos de BGP 4
CIDR y direcciones de agrupación
Confederación de BGP
Reflectores de ruta
Amortiguación de la inestabilidad de las rutas
Selección de un trayecto por parte de BGP
Estudios de casos de BGP 5
Ejemplo de diseño práctico
Introducción
Este documento contiene cinco conjuntos de estudios de casos relacionados con el Protocolo de gateway de frontera (BGP).
Requisitos previos
Requisitos
No hay requisitos específicos para este documento.
Componentes utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y hardware.
Convenciones
Consulte Cisco Technical Tips Conventions (Convenciones sobre consejos técnicos de Cisco) para obtener más información sobre las
convenciones del documento.
Estudios de casos de BGP 1
El BGP, que se define en RFC 1771 , permite crear enrutamientos interdominio sin bucles entre sistemas autónomos (AS). Un sistema
autónomo es un conjunto de routers bajo una sola administración técnica. Los routers de un AS pueden usar varios protocolos de gateway interior
(IGP) para intercambiar información de enrutamiento dentro del sistema autónomo. Los routers pueden usar un protocolo de gateway exterior
(EGP) para enrutar paquetes fuera del AS.
¿Cómo funciona BGP?
BGP usa TCP como el protocolo de transporte en el puerto 179. Dos routers BGP forman una conexión TCP entre sí. Estos routers son routers
pares, que intercambian mensajes para abrir y confirmar los parámetros de conexión.
Los routers BGP intercambian información de accesibilidad de la red. Esta información es, básicamente, una indicación de los trayectos
completos que debe tomar un router para alcanzar la red de destino. Los trayectos son números de AS BGP. Esta información ayuda a crear un
gráfico de los AS sin bucles. El gráfico muestra también dónde deben aplicarse las políticas de enrutamiento para imponer algunas restricciones
en el comportamiento del enrutamiento.
Dos routers cualquiera que formen una conexión TCP para intercambiar información de enrutamiento BGP son "pares" o "vecinos". Los pares
BGP intercambian inicialmente las tablas completas de enrutamiento BGP. Tras este intercambio, envían actualizaciones incrementales a medida
que cambia la tabla de enrutamiento. BGP conserva un número de versión de la tabla BGP. El número de versión es el mismo para todos los
pares BGP y se modifica cada vez que BGP actualiza la tabla con los cambios en la información de enrutamiento. El envío de paquetes de señal
de mantenimiento garantiza que la conexión entre los pares BGP se mantenga activa. Los paquetes de notificación se generan en respuesta a
errores o condiciones especiales.
eBGP e iBGP
Si un sistema autónomo (AS) tiene varios interlocutores BGP, puede servir como un servicio de tránsito para otros AS. Como muestra el
diagrama de esta sección, AS200 es un AS de tránsito para AS100 y AS300.
Para enviar la información a AS externos, es necesario asegurarse de que es posible tener acceso a las redes. Para garantizar esta accesibilidad, se
ejecutan los procesos siguientes:
Establecimiento de pares iBGP (BGP interno) entre routers dentro de un AS
Redistribución de información de BGP a los IGP que se ejecutan en el AS
Cuando BGP se ejecuta entre routers que pertenecen a dos AS diferentes, recibe el nombre de BGP externo (eBGP). Cuando BGP se ejecuta entre
routers del mismo AS, recibe el nombre de iBGP.
Habilitación del enrutamiento BGP
Siga los pasos siguientes para habilitar y configurar BGP.
Supongamos que desea tener dos routers, RTA y RTB, que se comuniquen a través de BGP. En el primer ejemplo, RTA y RTB se encuentran en
AS diferentes. En el segundo, los dos routers pertenecen al mismo AS.
1. Defina el proceso de enrutamiento y el número de AS al que pertenecen los routers.
Ejecute el comando siguiente para habilitar BGP en un router:
router bgp autonomous-system
RTA#
router bgp 100
RTB#
router bgp 200
Estas sentencias indican que RTA ejecuta BGP y que pertenece a AS100. RTB ejecuta BGP y pertenece a AS200.
2. Defina los vecinos BGP.
La formación de vecinos BGP identifica los routers que intentarán conectarse mediante BGP. En la sección Formación de vecinos BGP se
explica este proceso.
Formación de vecinos BGP
Dos routers BGP se convierten en vecinos cuando establecen una conexión TCP entre sí. La conexión TCP es esencial para que los dos routers
pares inicien el intercambio de actualizaciones de enrutamiento.
Cuando la conexión TCP está activa, los routers envían mensajes abiertos para intercambiar valores. Estos valores son el número de AS, la
versión de BGP que ejecutan, el ID del router BGP y el tiempo de espera de la señal de mantenimiento. Tras confirmarlos y aceptarlos, se
establece la conexión con el vecino. Cualquier estado diferente a Established indica que los dos routers no se han convertido en vecinos y
que no pueden intercambiar actualizaciones BGP.
Ejecute este comando neighbor para establecer una conexión TCP:
neighbor ip-address remote-as number
En el comando, number es el número de AS del router al que desea conectar con BGP. ip-address es la dirección de salto siguiente con
conexión directa para eBGP. En iBGP, ip-address es una dirección IP en otro router.
Las dos direcciones IP que usa en el comando neighbor de los routers pares deben poder conectarse entre sí. Una forma de verificar la
accesibilidad es efectuar un ping ampliado entre las dos direcciones IP. El ping ampliado obliga al router que hace ping a usar como origen la
dirección IP que especifica el comando neighbor. Debe usar esta dirección en lugar de la dirección IP de la interfaz desde la que se transfiere el
paquete.
Si se produce algún cambio en la configuración de BGP, debe reiniciar la conexión con el vecino para permitir que los nuevos parámetros tengan
efecto.
clear ip bgp address
Nota: address es la dirección del vecino.
clear ip bgp *
Este comando borra todas las conexiones vecinas.
De forma predeterminada, las sesiones BGP empiezan usando la versión 4 de BGP y, si es necesario, negocian de manera descendente hacia
versiones anteriores. Puede impedir las negociaciones e imponer la versión de BGP que usan los routers para comunicarse con un vecino. Ejecute
el comando siguiente en el modo de configuración del router:
neighbor {ip address | peer-group-name} version value
A continuación se proporciona un ejemplo de la configuración del comando neighbor:
RTA#
router bgp 100
neighbor 129.213.1.1 remote-as 200
RTB#
router bgp 200
neighbor 129.213.1.2 remote-as 100
neighbor 175.220.1.2 remote-as 200
RTC#
router bgp 200
neighbor 175.220.212.1 remote-as 200
En este ejemplo, RTA y RTB ejecutan eBGP. RTB y RTC ejecutan iBGP. El número de AS remoto señala un AS externo o interno, lo que indica
eBGP o iBGP. Además, los pares eBGP tienen conexión directa, pero los pares iBGP no. Los routers iBGP no la necesitan. Sin embargo, debe
haber algún IGP en ejecución que permita que dos vecinos puedan conectarse entre sí.
En esta sección se ofrece un ejemplo de la información que muestra el comando show ip bgp neighbors.
Nota: ponga especial atención al estado de BGP. Cualquier estado que no sea Established indica que los pares no funcionan.
Nota: observe también los elementos siguientes:
La entrada BGP version, que es 4
La entrada remote router ID
Este número es la dirección IP más elevada en el router, o la interfaz de bucle de retorno más elevada, si la hay.
La entrada table version
La entrada table version informa del estado de la tabla. Cada vez que se especifica información nueva, la tabla incrementa la versión.
Si una versión continúa incrementándose, significa que hay alguna ruta inestable que provoca la actualización continuada de las rutas.
# show ip bgp neighbors
BGP neighbor is 129.213.1.1, remote AS 200, external link
BGP version 4, remote router ID 175.220.12.1
BGP state = Established, table version = 3, up for 0:10:59
Last read 0:00:29, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 2828 messages, 0 notifications, 0 in queue
Sent 2826 messages, 0 notifications, 0 in queue
Connections established 11; dropped 10
BGP y las interfaces de bucle de retorno
Es muy habitual en iBGP usar una interfaz de bucle de retorno para definir vecinos, pero no lo es en eBGP. Generalmente, una interfaz de bucle
de retorno se usa para verificar si la dirección IP del vecino está activa y no depende de que el hardware funcione correctamente. En el caso de
eBGP, los routers pares tienen habitualmente conexión directa y el bucle de retorno no se aplica.
Si usa la dirección IP de una interfaz de bucle de retorno en el comando neighbor necesita configuración adicional en el router vecino. El router
vecino debe informar a BGP del uso de una interfaz de bucle de retorno, en lugar de una interfaz física, para iniciar la conexión TCP del BGP
vecino. Para indicar una interfaz de bucle de retorno, ejecute el comando siguiente:
neighbor ip-address update-source interface
Este ejemplo muestra el uso de este comando:
RTA#
router bgp 100
neighbor 190.225.11.1 remote-as 100
neighbor 190.225.11.1 update-source loopback 1
RTB#
router bgp 100
neighbor 150.212.1.1 remote-as 100
En este ejemplo, RTA y RTB ejecutan iBGP dentro de AS100. En el comando neighbor, RTB usa la interfaz de bucle de retorno de RTA,
150.212.1.1. En este caso, RTA debe obligar a BGP a que use la dirección IP del bucle de retorno como el origen de la conexión TCP del vecino.
Para forzar esta acción, RTA agrega update-source interface-type interface-number de modo que el comando es neighbor 190.225.11.1
update-source loopback 1. Esta sentencia obliga a BGP a usar la dirección IP de la interfaz de bucle de retorno cuando BGP se comunica con
190.225.11.1.
Nota: RTA ha usado la dirección IP de la interfaz física de RTB, 190.225.11.1, como un vecino. El uso de esta dirección IP es el motivo por el
que RTB no requiere una configuración especial. Consulte Sample Configuration for iBGP and eBGP With or Without a Loopback Address
(Ejemplo de configuración de iBGP y eBGP con o sin dirección de bucle de retorno) para obtener una configuración completa de ejemplo del
escenario de red.
eBGP de varios saltos
En algunos casos, el router de Cisco puede ejecutar eBGP con un router de otro fabricante que no permita la conexión directa de los dos pares
externos. Para conseguir la conexión, puede usar el eBGP de varios saltos. El eBGP de varios saltos permite una conexión vecina entre dos pares
externos que no tienen conexión directa. El eBGP de varios saltos sólo se aplica a eBGP y no a iBGP. El ejemplo siguiente muestra el eBGP de
varios saltos:
RTA#
router bgp 100
neighbor 180.225.11.1 remote-as 300
neighbor 180.225.11.1 ebgp-multihop
RTB#
router bgp 300
neighbor 129.213.1.2 remote-as 100
RTA indica un vecino externo que no tiene conexión directa. RTA debe indicar su uso del comando ebgp-multihop. Por otra parte, RTB indica
un vecino que tiene conexión directa, que es 129.213.1.2. Debido a esta conexión directa, RTB no necesita el comando ebgp-multihop. También
debería configurar un IGP o enrutamiento estático para permitir que los vecinos sin conexión puedan conectarse entre sí.
El ejemplo de la sección eBGP de varios saltos (balance de carga) muestra cómo se puede conseguir un balance de carga con BGP en caso de
tener eBGP en líneas paralelas.
eBGP de varios saltos (balance de carga)
RTA#
int loopback 0
ip address 150.10.1.1 255.255.255.0
router bgp 100
neighbor 160.10.1.1 remote-as 200
neighbor 160.10.1.1 ebgp-multihop
neighbor 160.10.1.1 update-source loopback 0
network 150.10.0.0
ip route 160.10.0.0 255.255.0.0 1.1.1.2
ip route 160.10.0.0 255.255.0.0 2.2.2.2
RTB#
int loopback 0
ip address 160.10.1.1 255.255.255.0
router bgp 200
neighbor 150.10.1.1 remote-as 100
neighbor 150.10.1.1 update-source loopback 0
neighbor 150.10.1.1 ebgp-multihop
network 160.10.0.0
ip route 150.10.0.0 255.255.0.0 1.1.1.1
ip route 150.10.0.0 255.255.0.0 2.2.2.1
Este ejemplo muestra el uso de las interfaces de bucle de retorno update-source y ebgp-multihop. Se trata de una solución provisional para
conseguir el balance de carga entre dos interlocutores eBGP en líneas de serie paralelas. En situaciones normales, BGP selecciona una de las
líneas en las que envía paquetes, y el balance de carga no tiene lugar. Con la introducción de las interfaces de bucle de retorno, el siguiente salto
para eBGP es la interfaz de bucle de retorno. Se usan rutas estáticas o un IGP para introducir dos trayectos de igual costo para conseguir
comunicarse con el destino. RTA tiene dos opciones para alcanzar el salto siguiente 160.10.1.1: un trayecto mediante 1.1.1.2 y otro mediante
2.2.2.2. RTB tiene las mismas opciones.
Correspondencias de la ruta
Las correspondencias de la ruta se usan con mucha frecuencia en BGP. En este contexto, es un método para controlar y modificar la información
de enrutamiento. El control y la modificación de la información de enrutamiento se efectúan mediante la definición de condiciones para la
redistribución de rutas de un protocolo de enrutamiento a otro. Aunque también se puede efectuar en la inyección de entrada y de salida de BGP.
El formato de una correspondencia de la ruta es el siguiente:
route-map map-tag [[permit | deny] | [sequence-number]]
La etiqueta de correspondencia es un nombre que se proporciona a la correspondencia de la ruta. Puede definir varias instancias de la misma
correspondencia o la misma etiqueta de nombre. El número de secuencia indica la posición que debe tener una nueva correspondencia de la ruta
en la lista de correspondencias que ya ha configurado con el mismo nombre.
En este ejemplo, se han definido dos instancias de correspondencia de la ruta con el nombre MYMAP. La primera tiene un número de secuencia
de 10 y la segunda, de 20.
route-map MYMAP permit 10 (el primer conjunto de condiciones se indica aquí).
route-map MYMAP permit 20 (el segundo conjunto de condiciones se indica aquí).
Cuando aplique la correspondencia de la ruta MYMAP a las rutas de entrada o salida, se aplica el primer conjunto de condiciones mediante la
instancia 10. Si no se cumple con el primer conjunto de condiciones, debe usar una instancia superior de la correspondencia de la ruta.
Comandos de configuración match y set
Cada correspondencia de la ruta consiste en una lista de comandos de configuración match y set. El primero especifica un criterio match y el
segundo una acción set si se cumplen los criterios que impone el comando match.
Por ejemplo, puede definir una correspondencia de la ruta que verifique las actualizaciones de salida. Si hay una concordancia para la dirección
IP 1.1.1.1, la métrica para dicha actualización se establece en 5. Estos comandos ilustran el ejemplo:
match ip address 1.1.1.1
set metric 5
Si se cumple con los criterios de concordancia y se tiene un valor permit, hay una redistribución o control de las rutas, como especifica la acción
set. Se encontrará fuera de la lista.
Si se cumple con los criterios de concordancia y se tiene un valor deny, no hay una redistribución o control de la ruta. Se encontrará fuera de la
lista.
Si no se cumple con los criterios de concordancia y se tiene un valor permit o deny, se verifica la siguiente instancia de la correspondencia de la
ruta. Se verifica, por ejemplo, la instancia 20. Esta verificación de la siguiente instancia continúa hasta que se encuentra fuera o finaliza todas las
instancias de la correspondencia de la ruta. Si finaliza la lista sin encontrar ninguna concordancia, la ruta no se acepta ni se reenvía.
En versiones anteriores a la versión 11.2 del software Cisco IOS®, cuando se usan correspondencias de la ruta para filtrar actualizaciones BGP
en lugar de redistribuir entre protocolos, no se puede filtrar en la salida cuando se usa un comando match en la dirección IP. Un filtro de salida se
puede aceptar. La versión 11.2 y posteriores del software Cisco IOS no tienen esta restricción.
Los comandos relacionados de match son los siguientes:
match as-path
match community
match clns
match interface
match ip address
match ip next-hop
match ip route-source
match metric
match route-type
match tag
Los comandos relacionados de set son los siguientes:
set as-path
set clns
set automatic-tag
set community
set interface
set default interface
set ip default next-hop
set level
set local-preference
set metric
set metric-type
set next-hop
set origin
set tag
set weight
Examine algunos ejemplos de correspondencia de la ruta:
Ejemplo 1
Supongamos que RTA y RTB ejecutan el Protocolo de información de enrutamiento (RIP), y que RTA y RTC ejecutan BGP. RTA recibe las
actualizaciones mediante BGP y las redistribuye a RIP. Imaginemos que RTA desea redistribuir a las rutas RTB de 170.10.0.0 con una métrica de
2 y el resto de rutas con una métrica de 5. En este caso, puede usar la configuración siguiente:
RTA#
router rip
network 3.0.0.0
network 2.0.0.0
network 150.10.0.0
passive-interface Serial0
redistribute bgp 100 route-map SETMETRIC
router bgp 100
neighbor 2.2.2.3 remote-as 300
network 150.10.0.0
route-map SETMETRIC permit 10
match ip-address 1
set metric 2
route-map SETMETRIC permit 20
set metric 5
access-list 1 permit 170.10.0.0 0.0.255.255
En este ejemplo, si una ruta concuerda con la dirección IP 170.10.0.0, la ruta tiene una métrica de 2. Por lo tanto, se encuentra fuera de la lista de
correspondencias de la ruta. Si no hay ninguna concordancia, sigue por la lista hacia abajo, lo que significa que el resto se establece en la métrica
5.
Nota: hágase siempre la pregunta "¿Qué ocurre a las rutas que no concuerdan con ninguna sentencia de coincidencia?". De forma
predeterminada, estas rutas se descartan.
Ejemplo 2
Supongamos que en el ejemplo 1 no desea que AS100 acepte actualizaciones de 170.10.0.0. No puede aplicar correspondencias de la ruta en la
salida cuando hay una concordancia con una dirección IP como base. Debe usar, por lo tanto, una correspondencia de la ruta de salida en RTC:
RTC#
router bgp 300
network 170.10.0.0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map STOPUPDATES out
route-map STOPUPDATES permit 10
match ip address 1
access-list 1 deny 170.10.0.0 0.0.255.255
access-list 1 permit 0.0.0.0 255.255.255.255
Ahora que ya sabe cómo iniciar BGP y cómo definir un vecino, observe cómo se inicia el intercambio de información de red.
Hay varias formas de enviar la información de red con BGP. Estas secciones analizan los métodos uno por uno:
El comando network
Redistribución
Rutas estáticas y redistribución
El comando network
El formato del comando network es:
network network-number [mask network-mask]
El comando network controla las redes que se originan desde este recuadro. Este concepto difiere de la configuración más habitual que se
efectúa con el Protocolo de enrutamiento de gateway interior (IGRP) y RIP. Con este comando, el usuario no intenta ejecutar BGP en una
determinada interfaz. En su lugar, intenta indicar a BGP las redes BGP que se deben originar desde este recuadro. El comando usa una porción de
máscara porque la versión 4 de BGP (BGP4) puede gestionar subredes y superredes. Se acepta un máximo de 200 entradas del comando network.
network funciona si el router tiene conocimiento de la red que se intenta anunciar, ya sea una red conectada, estática o cuyo conocimiento se
haya adquirido de forma dinámica.
Un ejemplo del comando network es:
RTA#
router bgp 1
network 192.213.0.0 mask 255.255.0.0
ip route 192.213.0.0 255.255.0.0 null 0
Este ejemplo indica que el router A genera una entrada de red para 192.213.0.0/16. /16 indica que usa una superred de la dirección de clase C y
que anuncia los dos primeros octetos o los primeros 16 bits.
Nota: necesita la ruta estática para que el router genere 192.213.0.0 porque la ruta estática incluye una entrada concordante en la tabla de
enrutamiento.
Redistribución
El comando network es una forma de anunciar las redes mediante BGP. Otra forma es redistribuir IGP en BGP. El IGP puede ser IGRP, el
protocolo Abrir trayecto más corto primero (OSPF), RIP, el Protocolo de enrutamiento de gateway interior mejorado (EIGRP) u otros protocolos.
Esta redistribución puede asustar un poco porque ahora se vuelcan todas las rutas internas en BGP; se ha obtenido conocimiento de algunas de
estas rutas mediante BGP y no es necesario volver a enviarlas. Aplique un filtro prudente para asegurarse de que envía a Internet sólo las rutas
que desea anunciar y no todas las rutas de que las dispone. A continuación se proporciona un ejemplo:
RTA anuncia 129.213.1.0 y RTC anuncia 175.220.0.0. Observe la configuración de RTC:
Si ejecuta el comando network, obtendrá lo siguiente:
RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote-as 300
network 175.220.0.0 mask 255.255.0.0
!--- Limita las redes que los AS originan en 175.220.0.0.
En cambio, si usa la redistribución, obtendrá lo siguiente:
RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote-as 300
redistribute eigrp 10
!--- EIGRP vuelve a inyectar 129.213.1.0 en BGP.
Esta redistribución hace que el AS origine 129.213.1.0. El usuario no es el origen de 129.213.1.0; lo es AS100. Debe usar filtros para evitar que
el AS sea el origen de dicha red. La configuración correcta es la siguiente:
RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote-as 300
neighbor 1.1.1.1 distribute-list 1 out
redistribute eigrp 10
access-list 1 permit 175.220.0.0 0.0.255.255
El comando access-list se usa para controlar las redes que se originan en AS200.
La redistribución de OSPF en BGP varía ligeramente de la redistribución de otros IGP. La simple ejecución del comando redistribute ospf 1 en
router bgp no funciona. Determinadas palabras clave como internal, external y nssa-external son necesarias para redistribuir las rutas
respectivas. Consulte Understanding Redistribution of OSPF Routes into BGP (Introducción a la redistribución de las rutas OSPF en el BGP)
para obtener más información.
Rutas estáticas y redistribución
Siempre puede usar las rutas estáticas para originar una red o una subred. La única diferencia es que BGP considera que estas rutas tienen un
origen incompleto o desconocido. Puede conseguir el mismo resultado que en el ejemplo de la sección Redistribución con:
RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote-as 300
redistribute static
...
ip route 175.220.0.0 255.255.255.0 null0
....
La interfaz null0 significa que el paquete no se toma en cuenta. Por lo tanto, si recibe el paquete y hay una coincidencia más específica que
175.220.0.0, que existe, el router envía el paquete a la específica. De lo contrario, el router no toma en cuenta el paquete. Este método es una
buena manera de anunciar una superred.
En este documento se analiza el uso de diferentes métodos para originar rutas fuera del AS. Recuerde que estas rutas se generan además de otras
rutas BGP cuyo conocimiento ha adquirido BGP a través de vecinos, ya sean internos o externos. BGP transfiere la información que BGP ha
adquirido de un par a otros pares. La diferencia es que las rutas que se generan con el comando network, ya sean de redistribución o estáticas,
indican el AS como el origen de estas redes.
La redistribución siempre es el método para inyectar BGP en IGP.
A continuación se proporciona un ejemplo:
RTA#
router bgp 100
neighbor 150.10.20.2 remote-as 300
network 150.10.0.0
RTB#
router bgp 200
neighbor 160.10.20.2 remote-as 300
network 160.10.0.0
RTC#
router bgp 300
neighbor 150.10.20.1 remote-as 100
neighbor 160.10.20.1 remote-as 200
network 170.10.00
Nota: no necesita la red 150.10.0.0 o la red 160.10.0.0 en RTC a menos que desee que RTC genere estas redes y que las transfiera tal como
llegan desde AS100 y AS200. La diferencia vuelve a ser que el comando network agrega un anuncio adicional para estas mismas redes, lo que
indica que AS300 también es un origen para estas rutas.
Nota: recuerde que BGP no acepta actualizaciones que se hayan originado desde su propio AS. Este rechazo garantiza una topología
interdominio sin bucles.
Supongamos, por ejemplo, que AS200 en el ejemplo de esta sección tiene una conexión directa BGP en AS100. RTA genera una ruta 150.10.0.0
y la envía a AS300. A continuación, RTC transfiere esta ruta a AS200 y mantiene el origen como AS100. RTB transfiere 150.10.0.0 a AS100
cuando el origen todavía es AS100. RTA se da cuenta de que la actualización se ha originado desde su AS y la omite.
iBGP
iBGP se usa si un AS desea actuar como un sistema de tránsito para otros AS. ¿Es verdad que puede hacer lo mismo si tiene conocimiento del
tráfico mediante eBGP, lo redistribuye en IGP y lo vuelve a redistribuir otra vez en otro AS? Sí, pero iBGP ofrece más flexibilidad y es un
método mucho más eficiente para intercambiar información dentro de un AS. iBGP ofrece métodos, por ejemplo, para controlar el mejor punto
de salida del AS con el uso de la preferencia local. La sección Atributo de preferencia local proporciona más información sobre la preferencia
local.
RTA#
router bgp 100
neighbor 190.10.50.1 remote-as 100
neighbor 170.10.20.2 remote-as 300
network 150.10.0.0
RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
neighbor 175.10.40.1 remote-as 400
network 190.10.50.0
RTC#
router bgp 400
neighbor 175.10.40.2 remote-as 100
network 175.10.0.0
Nota: recuerde que cuando un interlocutor BGP recibe una actualización de otros interlocutores BGP en su propio AS (iBGP), el interlocutor
BGP que recibe la actualización no redistribuye esa información a otros interlocutores de su AS. El interlocutor BGP que la recibe redistribuye la
información a otros interlocutores BGP fuera del AS. Por lo tanto, mantiene una interconexión completa entre los interlocutores iBGP dentro de
un AS.
En el diagrama de esta sección, RTA y RTB ejecutan iBGP. RTA y RTD también ejecutan iBGP. Las actualizaciones de BGP que proceden de
RTB y tienen como destino RTA se transmiten a RTE, que está fuera del AS. Las actualizaciones no se transmiten a RTD, que está dentro del
AS. Por lo tanto, cree pares iBGP entre RTB y RTD para no romper el flujo de actualizaciones.
El algoritmo de decisión BGP
Después de que BGP recibe actualizaciones sobre diferentes destinos desde distintos sistemas autónomos, el protocolo debe elegir los trayectos
para tener acceso a un determinado destino. BGP elige solamente un único trayecto para tener acceso a un destino.
BGP basa la decisión en diferentes atributos como salto siguiente, peso administrativo, preferencia local, origen del trayecto, longitud del
trayecto, código de origen, métrica y otros.
BGP siempre propaga el mejor trayecto a los vecinos. Consulte BGP Best Path Selection Algorithm (Algoritmo de selección del mejor trayecto
BGP) para obtener más información.
La sección Estudios de casos de BGP 2 explica estos atributos y su uso.
Estudios de casos de BGP 2
Atributo AS_PATH
Cada vez que una actualización de ruta pasa por un sistema autónomo (AS), el número de AS se agrega a dicha actualización. El atributo
AS_PATH es la lista de números de AS que una ruta atraviesa para llegar a su destino. Un atributo AS_SET es un conjunto {} ordenado
matemáticamente de todos los AS que se han atravesado. La sección Ejemplo de CIDR 2 (as-set) de este documento ofrece un ejemplo de
AS_SET.
En el ejemplo de esta sección, RTB anuncia la red 190.10.0.0 en AS200. Cuando dicha ruta atraviesa AS300, RTC agrega su propio número de
AS a la red. Por lo tanto, cuando 190.10.0.0 llega a RTA, la red tiene dos números de AS agregados: primero 200 y después 300. Para RTA, el
trayecto al que debe tener acceso 190.10.0.0 es (300, 200).
El mismo proceso se aplica a 170.10.0.0 y 180.10.0.0. RTB debe tomar el trayecto (300, 100); RTB atraviesa AS300 y después AS100 para tener
acceso a 170.10.0.0. RTC debe atravesar el trayecto (200) para tener acceso a 190.10.0.0 y el trayecto (100) para tener acceso a 170.10.0.0.
Atributo de origen
El origen es un atributo obligatorio que define el origen de la información de trayecto. Este atributo puede asumir tres valores:
IGP: la información de accesibilidad de la capa de red (NLRI) es un atributo interno al AS de origen. Normalmente tiene lugar cuando se
ejecuta el comando bgp network. Una i en la tabla BGP indica IGP.
EGP: la NLRI se recibe mediante el Protocolo de gateway exterior (EGP). Una e en la tabla BGP indica EGP.
INCOMPLETE: la NLRI se desconoce o se tiene conocimiento de ella por otros medios. INCOMPLETE tiene lugar cuando se
redistribuyen rutas desde otros protocolos de enrutamiento en BGP y el origen de la ruta es incompleto. Una ? en la tabla BGP indica
INCOMPLETE.
RTA#
router bgp 100
neighbor 190.10.50.1 remote-as 100
neighbor 170.10.20.2 remote-as 300
network 150.10.0.0
redistribute static
ip route 190.10.0.0 255.255.0.0 null0
RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
network 190.10.50.0
RTE#
router bgp 300
neighbor 170.10.20.1 remote-as 100
network 170.10.0.0
RTA tiene acceso a 170.10.0.0 mediante 300 i. "300 i" significa que el próximo trayecto de AS es 300 y que el origen de la ruta es IGP. RTA
también tiene acceso a 190.10.50.0 mediante i. "i" significa que la entrada se encuentra en el mismo AS y que el origen es IGP. RTE tiene acceso
a 150.10.0.0 mediante 100 i. "100 i" significa que el próximo AS es 100 y que el origen es IGP. RTE también tiene acceso a 190.10.0.0 con 100
?. "100 ?" significa que el próximo AS es 100 y que el origen es incompleto y procede de una ruta estática.
Atributo de salto siguiente de BGP
El atributo del salto siguiente de BGP es la dirección IP de salto siguiente que se debe usar para tener acceso a un determinado destino.
Para eBGP, el salto siguiente siempre es la dirección IP del vecino que especifica el comando neighbor. En el ejemplo de esta sección, RTC
anuncia 170.10.0.0 a RTA con un salto siguiente de 170.10.20.2. RTA anuncia 150.10.0.0 a RTC con un salto siguiente de 170.10.20.1. Para
iBGP, el protocolo indica que el salto siguiente que eBGP anuncia debe llevarse a cabo en iBGP. Debido a esta regla, RTA anuncia 170.10.0.0 a
su par RTB iBGP con un salto siguiente de 170.10.20.2. Por lo tanto, según RTB, el salto siguiente al que debe tener acceso 170.10.0.0 es
170.10.20.2 y no 150.10.30.1.
Asegúrese de que RTB puede tener acceso a 170.10.20.2 mediante ICP. De no ser así, RTB descarta paquetes con el destino 170.10.0.0 porque
no se puede tener acceso a la dirección de salto siguiente. Por ejemplo, si RTB ejecuta iGRP, también puede ejecutar iGRP en una red RTA
170.10.0.0. iGRP debería ser pasivo en el enlace a RTC de forma que sólo se intercambie BGP.
RTA#
router bgp 100
neighbor 170.10.20.2
neighbor 150.10.50.1
network 150.10.0.0
RTB#
router bgp 100
neighbor 150.10.30.1
RTC#
router bgp 300
neighbor 170.10.20.1
network 170.10.0.0
remote-as 300
remote-as 100
remote-as 100
remote-as 100
Nota: RTC anuncia 170.10.0.0 a RTA con un salto siguiente igual a 170.10.20.2.
Nota: RTA anuncia 170.10.0.0 a RTB con un salto siguiente igual a 170.10.20.2. El salto siguiente de eBGP se lleva a cabo en iBGP.
Tenga especial cuidado cuando trabaje con redes de acceso múltiple y de acceso múltiple sin difusión (NBMA). En las secciones Salto siguiente
de BGP (redes de acceso múltiple) y Salto siguiente de BGP (NBMA) se proporcionan más detalles.
Salto siguiente de BGP (redes de acceso múltiple)
Este ejemplo muestra cómo se comporta el salto siguiente en una red de acceso múltiple como Ethernet.
Supongamos que RTC y RTD en AS300 ejecutan OSPF. RTC ejecuta BGP con RTA. RTC puede tener acceso a la red 180.20.0.0 a través de
170.10.20.3. Cuando RTC envía una actualización BGP a RTA respecto a 180.20.0.0, RTC usa como salto siguiente 170.10.20.3. RTC no usa su
propia dirección IP, 170.10.20.2. RTC emplea esta dirección porque la red entre RTA, RTC y RTD es una red de acceso múltiple. El uso que
hace RTA de RTD como salto siguiente para tener acceso a 180.20.0.0 es más práctico que el salto adicional mediante RTC.
Nota: RTC anuncia 180.20.0.0 a RTA con un salto siguiente igual a 170.10.20.3.
Si el medio común a RTA, RTC y RTD no es de acceso múltiple, sino NBMA, pueden producirse algunas complicaciones.
Salto siguiente de BGP (NBMA)
El medio común se representa como una nube en el diagrama. Si el medio común es una retransmisión de tramas o una nube de NBMA, el
comportamiento exacto es como si se tuviera conexión por Ethernet. RTC anuncia 180.20.0.0 a RTA con un salto siguiente de 170.10.20.3.
El problema es que RTA no tiene un circuito virtual permanente (PVC) directo con RTD y no puede tener acceso al salto siguiente. En este caso,
se produce un error en el enrutamiento.
El comando next-hop-self soluciona esta situación.
Comando next-hop-self
En situaciones con salto siguiente, como en el ejemplo de Salto siguiente de BGP (NBMA), puede usar el comando next-hop-self. La sintaxis es:
neighbor {ip-address | peer-group-name} next-hop-self
El comando next-hop-self permite obligar a BGP a que use una determinada dirección IP como salto siguiente.
En el ejemplo de Salto siguiente de BGP (NBMA), esta configuración soluciona el problema:
RTC#
router bgp 300
neighbor 170.10.20.1 remote-as 100
neighbor 170.10.20.1 next-hop-self
RTC anuncia 180.20.0.0 con un salto siguiente igual a 170.10.20.2.
Entrada posterior de BGP
En este diagrama, RTA y RTC ejecutan eBGP. RTB y RTC ejecutan eBGP. RTA y RTB ejecutan algún tipo de IGP, ya sea RIP, IGRP u otro
protocolo. Por definición, las actualizaciones de eBGP tienen una distancia de 20, que es menor que las distancias de IGP. Las distancias
predeterminadas son:
120 para RIP
100 para IGRP
90 para EIGRP
110 para OSPF
RTA recibe actualizaciones de 160.10.0.0 mediante dos protocolos de enrutamiento:
eBGP con una distancia de 20
IGP con una distancia superior a 20
De manera predeterminada, BGP tiene las distancias siguientes:
Distancia externa: 20
Distancia interna: 200
Distancia local: 200
Sin embargo, puede usar el comando distance para cambiar las distancias predeterminadas:
distance bgp external-distance internal-distance local-distance
RTA selecciona eBGP mediante RTC debido a la distancia más corta.
Si desea que RTA tenga conocimiento de 160.10.0.0 mediante RTB (IGP), tiene dos opciones:
Cambiar la distancia externa de eBGP o la distancia IGP.
Nota: este cambio no se recomienda.
Usar la entrada posterior de BGP.
La entrada posterior de BGP hace que la ruta IGP sea la ruta preferida.
Ejecute el comando network address backdoor.
La red configurada es la red a la que desea tener acceso mediante IGP. Para BGP, esta red recibe el mismo tratamiento que una asignada
localmente, a excepción de que las actualizaciones BGP no la anuncian.
RTA#
router eigrp 10
network 150.10.0.0
router bgp 100
neighbor 2.2.2.1 remote-as 300
network 160.10.0.0 backdoor
La red 160.10.0.0 se trata como una entrada local, pero no se anuncia como una entrada de red normal.
RTA tiene conocimiento de 160.10.0.0 de RTB mediante EIGRP con una distancia de 90. RTA también tiene conocimiento de la dirección de
RTC mediante eBGP con una distancia de 20. Normalmente, eBGP es la preferencia, pero debido al comando backdoor, lo es EIGRP.
Sincronización
Antes de analizar la sincronización, observe la siguiente situación: RTC en AS300 envía actualizaciones de 170.10.0.0. RTA y RTB ejecutan
iBGP, de manera que RTB recibe la actualización y puede tener acceso a 170.10.0.0 mediante el salto siguiente 2.2.2.1. Recuerde que el salto
siguiente se ejecuta mediante iBGP. Para tener acceso al salto siguiente, RTB debe enviar el tráfico a RTE.
Supongamos que RTA no tiene una red redistribuida 170.10.0.0 en IGP. En este punto, RTE no tiene conocimiento de la existencia de
170.10.0.0.
Si RTB empieza a anunciar a AS400 que RTB puede tener acceso a 170.10.0.0, el tráfico procedente de RTD que va a RTB con destino
170.10.0.0 circula y queda descartado en RTE.
La sincronización indica que si el AS transfiere tráfico de otro AS a un tercer AS, BGP no debería anunciar una ruta antes de que todos los
routers del AS tengan conocimiento de ella mediante IGP. BGP espera hasta que IGP ha propagado la ruta dentro del AS. A continuación, BGP
anuncia la ruta a pares externos.
En el ejemplo de esta sección, RTB espera tener conocimiento sobre 170.10.0.0 mediante IGP. A continuación, RTB empieza a enviar la
actualización a RTD. Puede hacer que RTB piense que IGP ha propagado la información si agrega una ruta estática en RTB que señale a
170.10.0.0. Asegúrese de que otros routers pueden tener acceso a 170.10.0.0.
Inhabilitación de la sincronización
En algunos casos no es necesaria la sincronización. Si no transfiere tráfico desde un AS diferente por su AS, puede inhabilitarla. También puede
inhabilitarla si todos los routers del AS ejecutan BGP. La inhabilitación de esta función permite incorporar menos rutas en su IGP y que BGP
confluya con mayor rapidez.
La inhabilitación no es automática. Si todos los routers del AS ejecutan BGP y no desea ejecutar IGP, el router no puede saberlo. El router espera
indefinidamente una actualización de IGP de una determinada ruta antes de enviar la ruta a pares externos. En este caso, debe inhabilitar la
sincronización manualmente para que el enrutamiento pueda funcionar correctamente:
router bgp 100
no synchronization
Nota: asegúrese de ejecutar el comando clear ip bgp address para restablecer la sesión.
RTB#
router bgp 100
network 150.10.0.0
neighbor 1.1.1.2 remote-as 400
neighbor 3.3.3.3 remote-as 100
no synchronization
!--- RTB incorpora 170.10.0.0 en su tabla de enrutamiento de IP y anuncia la red
!--- a RTD, incluso si RTB no tiene un trayecto IGP hasta 170.10.0.0.
RTD#
router bgp 400
neighbor 1.1.1.1 remote-as 100
network 175.10.0.0
RTA#
router bgp 100
network 150.10.0.0
neighbor 3.3.3.4 remote-as 100
Atributo de peso
El atributo de peso es un atributo definido por Cisco. Usa el peso para seleccionar el mejor trayecto; el peso se asigna localmente al router. El
valor sólo tiene sentido para el router específico y no se propaga ni se transfiere por ninguna de las actualizaciones de ruta. Un peso puede ser un
número del 0 al 65.535. Los trayectos que origina el router tienen un peso predeterminado de 32.768, y otros trayectos tienen un peso de 0.
Las rutas con un valor de peso superior tienen preferencia cuando hay varias rutas en el mismo destino. Consulte el ejemplo de esta sección. RTA
ha obtenido conocimiento de 175.10.0.0 mediante AS4. RTA propaga la actualización a RTC. RTB también ha obtenido conocimiento de
175.10.0.0 mediante AS4. RTB propaga la actualización a RTC. RTC tiene ahora dos formas de tener acceso a 175.10.0.0 y debe decidir el
camino que debe tomar. Si define el peso de las actualizaciones en RTC que proceden de RTA de modo que sea mayor que el peso de las que
proceden de RTB, está obligando a RTC a usar RTA como el salto siguiente para tener acceso a 175.10.0.0. Varios métodos consiguen esta
definición de peso:
Use el comando neighbor.
neighbor {ip-address | peer-group} weight weight
Use listas de acceso AS_PATH.
ip as-path access-list access-list-number {permit | deny} as-regular-expression neighbor ip-address filter-list access-listnumber weight weight
Use correspondencias de la ruta.
RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 weight 200
!--- La ruta a 175.10.0.0 de RTA tiene un peso de 200.
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 weight 100
!--- La ruta a 175.10.0.0 de RTB tiene un peso de 100.
RTA, que tiene un valor de peso superior, tiene preferencia como salto siguiente.
Puede conseguir el mismo resultado con IP AS_PATH y listas de filtro.
RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 filter-list 5 weight 200
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 filter-list 6 weight 100
...
ip as-path access-list 5 permit ^100$
!--- Esto sólo permite el trayecto 100.
ip as-path access-list 6 permit ^200$
...
También puede conseguir el mismo resultado con el uso de correspondencias de la ruta.
RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-map setweightin in
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 route-map setweightin in
...
ip as-path access-list 5 permit ^100$
...
route-map setweightin permit 10
match as-path 5
set weight 200
!--- Todo lo que se aplique a la lista de acceso 5, por ejemplo, paquetes de AS100, tiene un peso de 200
route-map setweightin permit 20
set weight 100
!--- Todo lo demás tiene un peso de 100.
Atributo de preferencia local
La preferencia local es una indicación al sistema autónomo (AS) del trayecto que tiene preferencia para salir del AS con el fin de alcanzar una
determinada red. Se prefiere un trayecto con una preferencia local superior. El valor predeterminado para la preferencia local es 100.
A diferencia de lo que sucede con el atributo de peso, que sólo es importante para el router local, la preferencia local es un atributo que los routers
intercambian en el mismo AS.
La preferencia local se define cuando se ejecuta el comando bgp default local-preference value . También puede definir la preferencia local con
las correspondencias de la ruta, como demuestra el ejemplo de esta sección:
El comando bgp default local-preference define la preferencia local en las actualizaciones que salen del router y se dirigen a los pares en el
mismo AS. En el diagrama de esta sección, AS256 recibe actualizaciones de 170.10.0.0 desde dos puntos distintos de la organización. La
preferencia local ayuda a determinar el camino de salida de AS256 para alcanzar dicha red. Supongamos que RTD es la preferencia de punto de
salida. Esta configuración define la preferencia local para las actualizaciones que proceden de AS300 hacia 200 y para las actualizaciones que
proceden de AS100 hacia 150:
RTC#
router bgp 256
neighbor 1.1.1.1 remote-as 100
neighbor 128.213.11.2 remote-as 256
bgp default local-preference 150
RTD#
router bgp 256
neighbor 3.3.3.4 remote-as 300
neighbor 128.213.11.1 remote-as 256
bgp default local-preference 200
En esta configuración, RTC define la preferencia local de todas las actualizaciones en 150. El mismo RTD define la preferencia local de todas las
actualizaciones en 200. Hay un intercambio de preferencia local dentro de AS256. Por consiguiente, tanto RTC como RTD se dan cuenta de que
la red 170.10.0.0 tiene una preferencia local superior cuando las actualizaciones proceden de AS300 en lugar de AS100. Todo el tráfico en
AS256 que tenga dicha red como destino transmite con RTD como punto de salida.
El uso de correspondencias de la ruta proporciona más flexibilidad. En el ejemplo de esta sección, todas las actualizaciones que recibe RTD se
etiquetan con la preferencia local 200 cuando llegan a RTD. Las actualizaciones que proceden de AS34 también se etiquetan con la preferencia
local de 200, etiqueta que puede que no sea necesaria. Por este motivo, puede usar correspondencias de la ruta para especificar las actualizaciones
que se deben etiquetar con una determinada preferencia local. A continuación se proporciona un ejemplo:
RTD#
router bgp 256
neighbor 3.3.3.4 remote-as 300
neighbor 3.3.3.4 route-map setlocalin in
neighbor 128.213.11.1 remote-as 256
....
ip as-path access-list 7 permit ^300$
...
route-map setlocalin permit 10
match as-path 7
set local-preference 200
route-map setlocalin permit 20
set local-preference 150
Con esta configuración, cualquier actualización procedente de AS300 tiene una preferencia local de 200. Cualquier otra, por ejemplo, las
procedentes de AS34, tienen un valor de 150.
Atributo de métrica
El atributo de métrica recibe el nombre de MULTI_EXIT_DISCRIMINATOR, MED (BGP4) o INTER_AS (BGP3). El atributo es una pista para
los vecinos externos sobre la preferencia de trayecto en un sistema autónomo (AS). El atributo ofrece una forma dinámica de influir en otro AS
para alcanzar una cierta ruta cuando hay múltiples puntos de entrada a dicho AS. Es preferible un valor métrico inferior.
A diferencia de lo que sucede con la preferencia local, los AS intercambian la métrica. Una métrica se ejecuta en un AS, pero no lo deja. Cuando
una actualización se registra en el AS con una determinada métrica, dicha métrica se usa para tomar decisiones dentro del AS. Cuando la misma
actualización se transfiere a un tercer AS, la métrica vuelve a ser 0. El diagrama de esta sección muestra la configuración de la métrica. El valor
predeterminado de la métrica es 0.
A menos que un router reciba otras direcciones, él mismo compara la métrica de los trayectos de los vecinos en el mismo AS. Para que el router
compare las métricas de los vecinos que proceden de diferentes AS, debe ejecutar el comando de configuración especial bgp always-comparemed en el router.
Nota: hay dos comandos de configuración BGP que pueden influir en la selección del trayecto basada en el discriminador de salidas múltiples
(MED). Los comandos son bgp deterministic-med y bgp always-compare-med. Si se ejecuta el comando bgp deterministic-med, se garantiza
la comparación de la variable MED en la elección de ruta cuando diferentes pares se anuncian en el mismo AS. Si se ejecuta el comando bgp
always-compare-med, se garantiza la comparación de MED para los trayectos de vecinos en diferentes AS. El comando bgp always-comparemed es de utilidad cuando múltiples proveedores de servicios o empresas acuerdan una política uniforme para configurar MED. Consulte How
the bgp deterministic-med Command Differs from the bgp always-compare-med Command (En qué se diferencia el comando bgp deterministicmed del comando bgp always-compare-med) para comprender la influencia de estos comandos en la selección de trayectos BGP.
En el diagrama de esta sección, AS100 recibe información sobre la red 180.10.0.0 desde tres routers diferentes: RTC, RTD y RTB. RTC y RTD
están en AS300, y RTB en AS400.
Supongamos que ha establecido la métrica que procede de RTC en 120, la que procede de RTD en 200 y la que procede de RTB en 50. De
manera predeterminada, un router compara la métrica que procede de los vecinos en el mismo AS. Por lo tanto, RTA sólo puede comparar la
métrica que procede de RTC con la que procede de RTD. RTA selecciona a RTC como el mejor salto siguiente porque 120 es menor que 200.
Cuando RTA recibe una actualización de RTB con la métrica 50, no puede comparar la métrica con 120 porque RTC y RTB están en AS
diferentes. RTA debe seleccionar en función de otros atributos.
Para obligar a RTA a que compare las métricas, debe ejecutar el comando bgp always-compare-med en RTA. Las configuraciones siguientes
muestran este proceso:
RTA#
router bgp 100
neighbor 2.2.2.1 remote-as 300
neighbor 3.3.3.3 remote-as 300
neighbor 4.4.4.3 remote-as 400
....
RTC#
router bgp 300
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map setmetricout out
neighbor 1.1.1.2 remote-as 300
route-map setmetricout permit 10
set metric 120
RTD#
router bgp 300
neighbor 3.3.3.2 remote-as 100
neighbor 3.3.3.2 route-map setmetricout out
neighbor 1.1.1.1 remote-as 300
route-map setmetricout permit 10
set metric 200
RTB#
router bgp 400
neighbor 4.4.4.4 remote-as 100
neighbor 4.4.4.4 route-map setmetricout out
route-map setmetricout permit 10
set metric 50
Con estas configuraciones, RTA selecciona a RTC como salto siguiente, porque se considera que todos los otros atributos son iguales. Para
incluir RTB en la comparación de la métrica, debe configurar RTA de la forma siguiente:
RTA#
router bgp 100
neighbor 2.2.21 remote-as 300
neighbor 3.3.3.3 remote-as 300
neighbor 4.4.4.3 remote-as 400
bgp always-compare-med
En este caso, RTA selecciona a RTB como el mejor salto siguiente para tener acceso a la red 180.10.0.0.
También puede definir la métrica durante la redistribución de las rutas en BGP si ejecuta el comando default-metric number .
Supongamos que en el ejemplo de esta sección, RTB inyecta una red por medio de un valor estático en AS100. Aquí está la configuración:
RTB#
router bgp 400
redistribute static
default-metric 50
ip route 180.10.0.0 255.255.0.0 null 0
!--- Hace que RTB envíe 180.10.0.0 con un métrica de 50.
Atributo de comunidad
El atributo de comunidad es un atributo transitivo y optativo en el intervalo de 0 a 4.294.967.200. Este atributo es una forma de agrupar destinos
en una determinada comunidad y de aplicar decisiones de enrutamiento según estas comunidades. Las decisiones de enrutamiento son, entre
otras, aceptar, preferir y redistribuir.
Puede usar las correspondencias de la ruta para establecer los atributos de la comunidad. El comando de la correspondencia de la ruta set tiene la
sintaxis siguiente:
set community community-number [additive] [well-known-community]
Algunas comunidades predefinidas y conocidas para usar en este comando son:
no-export: no anuncie a pares eBGP. Mantenga esta ruta dentro de un AS.
no-advertise: no anuncie esta ruta a ningún par interno o externo.
internet: anuncie esta ruta a la comunidad de Internet. Cualquier router pertenece a esta comunidad.
local-as: se usa en escenarios de confederación para evitar la transmisión de paquetes fuera del AS local.
A continuación se presentan dos ejemplos de correspondencias de la ruta que definen la comunidad:
route-map communitymap
match ip address 1
set community no-advertise
o
route-map setcommunity
match as-path 1
set community 200 additive
Si no define la palabra clave additive, 200 sustituye cualquier comunidad anterior que ya exista. Si usa la palabra clave additive, se produce una
adición de 200 a la comunidad. Aunque defina el atributo de comunidad, éste no se transmite a los vecinos de forma predeterminada. Para
enviarlo a un vecino, debe usar el comando siguiente:
neighbor {ip-address | peer-group-name} send-community
A continuación se proporciona un ejemplo:
RTA#
router bgp 100
neighbor 3.3.3.3 remote-as 300
neighbor 3.3.3.3 send-community
neighbor 3.3.3.3 route-map setcommunity out
En la versión 12.0 y posteriores del software Cisco IOS, puede configurar comunidades en tres formatos diferentes: decimal, hexadecimal y
AA:NN. De forma predeterminada, el software Cisco IOS usa el formato decimal anterior. Para configurar y mostrar en formato AA:NN, ejecute
el comando ip bgp-community new-format de configuración global. La primera parte de AA:NN representa el número de AS, y la segunda, un
número de 2 bytes.
A continuación se proporciona un ejemplo:
Sin el comando ip bgp-community new-format en la configuración global, al ejecutar el comando show ip bgp 6.0.0.0 se muestra el valor del
atributo de comunidad en formato decimal. En este ejemplo, el valor del atributo de comunidad aparece como 6553620.
Router# show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/8, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
1
10.10.10.1 from 10.10.10.1 (200.200.200.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 6553620
Ahora, ejecute el comando ip bgp-community new-format globalmente en este router.
Router# configure terminal
Enter configuration commands, one per line.
Router(config)# ip bgp-community new-format
Router(config)# exit
End with CNTL/Z.
Con el comando ip bgp-community new-format de configuración global, el valor de la comunidad se muestra en formato AA:NN. El valor se
muestra como 100:20 en el resultado del comando show ip bgp 6.0.0.0 de este ejemplo:
Router# show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/8, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
1
10.10.10.1 from 10.10.10.1 (200.200.200.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 100:20
Estudios de casos de BGP 3
Filtrado de BGP
Varios métodos de filtrado distintos permiten controlar el envío y la recepción de las actualizaciones BGP. Puede filtrar las actualizaciones BGP
con información de ruta como base, o con información de trayecto o de comunidades como base. Todos los métodos consiguen los mismos
resultados. La elección de uno sobre otro depende de la configuración de red específica.
Filtrado de ruta
Para limitar la información de enrutamiento que el router anuncia o de la que tiene conocimiento, puede filtrar BGP con actualizaciones de
enrutamiento a o desde un determinado vecino. Puede definir una lista de acceso y aplicarla a las actualizaciones que proceden o que están
destinadas a un vecino. Ejecute el comando siguiente en el modo de configuración del router:
neighbor {ip-address | peer-group-name} distribute-list access-list-number {in | out}
En este ejemplo, RTB se origina en la red 160.10.0.0 y envía la actualización a RTC. Si RTC desea detener la propagación de las actualizaciones
a AS100, debe definir una lista de acceso para filtrar dichas actualizaciones y aplicarla durante la comunicación con RTA:
RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 distribute-list 1 out
access-list 1 deny 160.10.0.0 0.0.255.255
access-list 1 permit 0.0.0.0 255.255.255.255
!--- Filtrar todas las actualizaciones de enrutamiento de 160.10.x.x.
El uso de listas de acceso es un poco difícil cuando se trabaja con superredes que pueden provocar algunos conflictos.
Supongamos que, en el ejemplo de esta sección, RTB tiene subredes diferentes de 160.10.x.x. El objetivo es filtrar actualizaciones y anunciar
solamente 160.0.0.0/8.
Nota: la anotación /8 significa que usa 8 bits de máscara de subred, que comienza a la izquierda de la dirección IP. Esta dirección es equivalente
a 160.0.0.0 255.0.0.0.
El comando access-list 1 permit 160.0.0.0. 0.255.255.255 permite 160.0.0.0/8, 160.0.0.0/9, etc. Para limitar la actualización a 160.0.0.0/8
solamente, debe usar una lista de acceso ampliada del formato siguiente:
access-list 101 permit ip 160.0.0.0 0.255.255.255 255.0.0.0 0.0.0.0.
Esta lista sólo permite 160.0.0.0/8.
Consulte How to Block One or More Networks From a BGP Peer (Bloqueo de una o más redes desde un par BGP) para obtener ejemplos de
configuraciones sobre cómo filtrar redes desde pares BGP. El método usa el comando distribute-list con listas de control de acceso (ACL)
estándar y ampliadas, así como filtros de lista de prefijos.
Filtrado de trayecto
Otro tipo de filtrado es el filtrado de trayecto.
Puede especificar una lista de acceso en las actualizaciones de entrada y salida si usa la información de trayecto del AS BGP. En el diagrama de
esta sección, puede bloquear las actualizaciones de 160.10.0.0 de modo que no se transfieran a AS100. Para ello, defina una lista de acceso en
RTC que impida la transmisión a AS100 de cualquier actualización que se haya originado desde AS200. Ejecute los comandos siguientes:
ip as-path access-list access-list-number {permit | deny} as-regular-expression
neighbor {ip-address | peer-group-name} filter-list access-list-number {in | out}
Este ejemplo detiene el envío de RTC de actualizaciones de 160.10.0.0 a RTA:
RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 filter-list 1 out
!--- 1 es el número de lista de acceso que se indica abajo.
ip as-path access-list 1 deny ^200$
ip as-path access-list 1 permit .*
El comando access-list 1 de este ejemplo obliga a denegar cualquier actualización con información de trayecto que se inicie con 200 y termine
con 200. ^200$ en el comando es una "expresión normal", en la que ^ significa "empieza por" y $ significa "termina por". Dado que RTB envía
actualizaciones de 160.10.0.0 con información de trayecto que comienza con 200 y termina con 200, las actualizaciones coinciden con la lista de
acceso. La lista de acceso deniega estas actualizaciones.
La entrada .* es otra expresión normal en la que . significa "cualquier carácter" y * significa "la repetición de dicho carácter". Por lo tanto, .*
representa cualquier información de trayecto, que es necesaria para permitir la transmisión de todas las otras actualizaciones.
¿Qué sucede si en lugar de usar ^200$, usa ^200? Con un AS400, como en el diagrama de esta sección, las actualizaciones que origina AS400
tienen información de trayecto del tipo (200, 400). En esta información de trayecto, 200 es el primero y 400, el último. Estas actualizaciones
concuerdan con la lista de acceso ^200 porque la información de trayecto empieza por 200. La lista de acceso impide la transmisión de estas
actualizaciones a RTA, lo que no es un requisito.
Para verificar si ha implementado la expresión normal correcta, ejecute el comando show ip bgp regexp regular-expression . Este comando
muestra todos los trayectos que han coincidido con la configuración de la expresión normal.
Expresión normal de AS
Esta sección explica la creación de una expresión normal.
Una expresión normal es un patrón que debe coincidir con una cadena de entrada. Cuando crea una expresión normal, especifica una cadena que
debe coincidir con la entrada. En el caso de BGP, especifica una cadena que consta de información de trayecto que debe coincidir con una
entrada.
En el ejemplo de la sección Filtrado de trayecto, especificó la cadena ^200$. Deseaba que la información de trayecto que incorporan las
actualizaciones coincidiera con la cadena para tomar una decisión.
Una expresión normal comprende:
Rango
Un rango es una secuencia de caracteres dentro de corchetes. Un ejemplo es [abcd].
Átomo
Un átomo es un único carácter. A continuación se muestran algunos ejemplos:
.
El símbolo . coincide con cualquier único carácter.
^
El símbolo ^ coincide con el inicio de la cadena de entrada.
$
El símbolo $ coincide con el final de la cadena de entrada.
\
El símbolo \ coincide con el carácter.
-
El símbolo _ coincide con coma (,), corchete redondo izquierdo ({), corchete redondo derecho (}), inicio de la cadena de entrada,
final de la cadena de entrada o espacio.
Pieza
Una pieza es uno de estos símbolos, que sigue a un átomo:
*
El símbolo * coincide con 0 o más secuencias del átomo.
+
El símbolo + coincide con 1 o más secuencias del átomo.
?
El símbolo ? coincide con el átomo o con la cadena nula.
Rama
Una rama es 0 o más piezas concatenadas.
A continuación se incluyen algunos ejemplos de expresiones normales:
a*
Esta expresión indica cualquier aparición de la letra "a", ninguna inclusive.
a+
Esta expresión indica que, como mínimo, debe haber un caso de letra "a".
ab?a
Esta expresión coincide con "aa" o "aba".
_100_
Esta expresión significa mediante AS100.
_100$
Esta expresión indica un origen de AS100.
^100 .*
Esta expresión indica una transmisión de AS100.
^$
Esta expresión indica un origen de este AS.
Consulte Using Regular Expressions in BGP (Uso de expresiones normales en BGP) para obtener ejemplos de configuraciones de filtrado de
expresiones normales.
Filtrado de comunidad BGP
Este documento ha analizado el filtrado de ruta y el filtrado de trayecto AS. Otro método es el filtrado de comunidad. En la sección Atributo de
comunidad se analiza la comunidad y se proporcionan algunos ejemplos de cómo usarla.
En este ejemplo, desea que RTB defina el atributo de comunidad en las rutas BGP que RTB anuncia, de modo que RTC no las propague a pares
externos. Use el atributo de comunidad no-export.
RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote-as 300
neighbor 3.3.3.1 send-community
neighbor 3.3.3.1 route-map setcommunity out
route-map setcommunity
match ip address 1
set community no-export
access-list 1 permit 0.0.0.0 255.255.255.255
Nota: este ejemplo utiliza el comando route-map setcommunity para definir la comunidad como no-export.
Nota: el comando neighbor send-community es necesario para enviar este atributo a RTC.
Cuando RTC recibe las actualizaciones con el atributo NO_EXPORT, no las propaga a un RTA de par externo.
En este ejemplo, RTB ha definido el atributo de comunidad en 100 200 additive. Esta acción agrega el valor 100 200 a cualquier valor de
comunidad existente antes de la transmisión a RTC.
RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote-as 300
neighbor 3.3.3.1 send-community
neighbor 3.3.3.1 route-map setcommunity out
route-map setcommunity
match ip address 2
set community 100 200 additive
access-list 2 permit 0.0.0.0 255.255.255.255
Una lista de comunidad es un grupo de comunidades que se usan en una cláusula match de una correspondencia de la ruta. La lista de
comunidades permite filtrar o definir atributos con listas diferentes de números de comunidad como base.
ip community-list community-list-number {permit | deny} community-number
Por ejemplo, puede definir esta correspondencia de la ruta, match-on-community:
route-map match-on-community
match community 10
!--- El número de la lista de comunidades es 10.
set weight 20
ip community-list 10 permit 200 300
!--- El número de comunidad es 200 300.
Puede usar la lista de comunidades para filtrar o definir ciertos parámetros, como peso y métrica, en algunas actualizaciones con el valor de la
comunidad como base. En el segundo ejemplo de esta sección, RTB envía actualizaciones a RTC con una comunidad de 100 200. Si RTC desea
definir el peso con dichos valores como base, puede hacer lo siguiente:
RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 3.3.3.3 route-map check-community in
route-map check-community permit 10
match community 1
set weight 20
route-map check-community permit 20
match community 2 exact
set weight 10
route-map check-community permit 30
match community 3
ip community-list 1 permit 100
ip community-list 2 permit 200
ip community-list 3 permit internet
En este ejemplo, cualquier ruta que tenga 100 en el atributo de comunidad coincide con la lista 1. El peso de esta ruta se define en 20. Cualquier
ruta que tenga solamente 200 como comunidad, coincide con la lista 2 y tiene un peso de 20. La palabra clave exact indica que la comunidad
consta de 200 y de nada más. La última lista de comunidades que se presenta aquí es para garantizar que no se descartan otras actualizaciones.
Recuerde que, como valor predeterminado, todo lo que no coincide se descarta. La palabra clave internet indica todas las rutas porque todas son
miembros de la comunidad de Internet.
Consulte Using BGP Community Values to Control Routing Policy in an Upstream Provider Network (Uso de los valores de la comunidad BGP
para controlar la política de enrutamiento en una red de proveedor ascendente) para obtener más información.
Vecinos y correspondencias de la ruta BGP
Puede usar el comando neighbor con las correspondencias de la ruta para filtrar o definir parámetros sobre actualizaciones de entrada y salida.
Las correspondencias de la ruta asociadas con la sentencia neighbor no tienen ningún efecto sobre las actualizaciones de entrada cuando la
coincidencia se efectúa en función de la dirección IP:
neighbor ip-address route-map route-map-name
Supongamos que en el diagrama de esta sección desea que RTC tenga conocimiento por parte de AS200 de las redes que son locales a AS200 y
nada más. Asimismo, desea definir el peso de las rutas aceptadas en 20. Use una combinación de listas de acceso neighbor y as-path:
RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote-as 200
neighbor 3.3.3.3 route-map stamp in
route-map stamp
match as-path 1
set weight 20
ip as-path access-list 1 permit ^200$
Cualquier actualización que se origine en AS200 tiene información de trayecto que comienza con 200 y finaliza con 200. Estas actualizaciones
están permitidas. Se descarta cualquier otra actualización.
Supongamos que desea lo siguiente:
Que se acepten las actualizaciones que se originan en AS200 y que tienen un peso de 20
Que se descarten las actualizaciones que se originan en AS400
Un peso de 10 para las otras actualizaciones
RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote-as 200
neighbor 3.3.3.3 route-map stamp in
route-map stamp permit 10
match as-path 1
set weight 20
route-map stamp permit 20
match as-path 2
set weight 10
ip as-path access-list 1 permit ^200$
ip as-path access-list 2 permit ^200 600 .*
Esta sentencia define un peso de 20 para las actualizaciones que son locales de AS200. También define un peso de 10 para las
actualizaciones que están detrás de AS400 y descarta las que proceden de AS400.
Uso del comando set as-path prepend
En algunas situaciones, debe modificar la información de trayecto para manipular el proceso de decisión de BGP. El comando que se usa con una
correspondencia de la ruta es:
set as-path prepend as-path#
as-path#
Supongamos que en el diagrama de la sección Vecinos y correspondencias de la ruta BGP, RTC anuncia su propia red 170.10.0.0 a dos sistemas
autónomos (AS) diferentes, AS100 y AS200. Cuando la información se propaga a AS600, los routers de AS600 tienen información de
accesibilidad de la red de 150.10.0.0 por dos rutas diferentes. La primera ruta es por AS100 con el trayecto (100, 300) y la segunda es por AS400
con el trayecto (400, 200, 300). Si todos los demás atributos son los mismos, AS600 selecciona el trayecto más corto y elige la ruta por AS100.
AS300 recibe todo el tráfico por AS100. Si desea influir en esta decisión desde el extremo de AS300, puede hacer que el trayecto que pasa por
AS100 parezca más largo que el trayecto que pasa por AS400. Para ello, agregue números de AS a la información de trayecto existente que se
anuncia en AS100. Una práctica común es repetir el propio número de AS de la forma siguiente:
RTC#
router bgp 300
network 170.10.0.0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map SETPATH out
route-map SETPATH
set as-path prepend 300 300
Debido a esta configuración, AS600 recibe actualizaciones de 170.10.0.0 por AS100 con información de trayecto de: (100, 300, 300, 300). Esta
información de trayecto es más larga que la información (400, 200, 300) que AS600 ha recibido de AS400.
Grupos de pares BGP
Un grupo de pares es un grupo de vecinos BGP con las mismas políticas de actualización. Las correspondencias de la ruta, las listas de
distribución y las listas de filtrado definen habitualmente dichas políticas. No se definen las mismas para cada vecino, sino que se define un
nombre de grupo de pares y se le asignan estas políticas.
Los miembros del grupo de pares heredan todas las opciones de configuración del grupo de pares. También puede configurar miembros para
anular estas opciones, si éstas no afectan a las actualizaciones de salida. Sólo puede anular opciones que se hayan definido en la entrada.
Para definir un grupo de pares, ejecute el comando siguiente:
neighbor peer-group-name peer-group
Este ejemplo aplica grupos de pares a vecinos BGP internos y externos:
RTC#
router bgp 300
neighbor internalmap peer-group
neighbor internalmap remote-as 300
neighbor internalmap route-map SETMETRIC out
neighbor internalmap filter-list 1 out
neighbor internalmap filter-list 2 in
neighbor 5.5.5.2 peer-group internalmap
neighbor 5.6.6.2 peer-group internalmap
neighbor 3.3.3.2 peer-group internalmap
neighbor 3.3.3.2 filter-list 3 in
Esta configuración define un grupo de pares con el nombre internalmap. La configuración establece algunas políticas para el grupo, como una
correspondencia de la ruta SETMETRIC para definir la métrica en 5, y dos listas de filtros diferentes, 1 y 2. La configuración aplica el grupo de
pares a todos los vecinos internos, RTE, RTF y RTG. La configuración establece también una lista de filtros 3 distinta para el vecino RTE. Esta
lista de filtros anula la lista de filtros 2 dentro del grupo de pares.
Nota: sólo puede anular opciones que afectan a las actualizaciones de entrada.
Ahora, observe cómo puede usar grupos de pares con vecinos externos. Con el mismo diagrama de esta sección, configure RTC con un grupo de
pares externalmap y aplique el grupo de pares a los vecinos externos.
RTC#
router bgp 300
neighbor externalmap peer-group
neighbor externalmap route-map SETMETRIC
neighbor externalmap filter-list 1 out
neighbor externalmap filter-list 2 in
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 peer-group externalmap
neighbor 4.4.4.2 remote-as 600
neighbor 4.4.4.2 peer-group externalmap
neighbor 1.1.1.2 remote-as 200
neighbor 1.1.1.2 peer-group externalmap
neighbor 1.1.1.2 filter-list 3 in
Nota: en estas configuraciones, se definen las sentencias remote-as fuera del grupo de pares porque se deben establecer distintos AS externos.
Anule también las actualizaciones de entrada del vecino 1.1.1.2 con la asignación de la lista de filtros 3.
Si desea obtener más información sobre los grupos de pares, consulte BGP Peer Groups (Grupos de pares BGP).
Nota: en la versión 12.0(24)S del software Cisco IOS, Cisco introdujo la función de actualización automática de grupos de pares BGP. Esta
función se encuentra también disponible en versiones posteriores del software Cisco IOS. La función introduce un nuevo algoritmo que calcula y
optimiza dinámicamente grupos de actualización de los vecinos que comparten las mismas políticas de salida. Estos vecinos pueden compartir los
mismos mensajes de actualización. En versiones anteriores de Cisco IOS, el grupo de mensajes de actualización de BGP era la base de las
configuraciones del grupo de pares. Este método para agrupar actualizaciones limitaba las políticas de salida y las configuraciones de sesión
específicas. La función de actualización dinámica de grupos de pares de BGP separa la réplica del grupo de actualización de la configuración del
grupo de pares. Esta separación mejora el tiempo de convergencia y la flexibilidad de la configuración del vecino. Consulte BGP Dynamic
Update Peer-Groups (Grupos de pares de actualización dinámica BGP) para obtener más información.
Estudios de casos de BGP 4
CIDR y direcciones de agrupación
Una de las principales mejoras de BGP4 en relación con BGP3 es el enrutamiento interdominio sin clase (CIDR). CIDR o superredes es una
nueva forma de considerar las direcciones IP. Con CIDR, no hay ninguna noción de clases, como clase A, B o C. La red 192.213.0.0, por
ejemplo, fue en su día una red de clase C ilegal. Ahora, la red es una superred legal, 192.213.0.0/16. "16" representa el número de bits de la
máscara de subred, si cuenta desde la izquierda de la dirección IP. Esta representación es similar a 192.213.0.0 255.255.0.0.
Las agrupaciones se usan para minimizar el tamaño de las tablas de enrutamiento. La agrupación es el proceso que combina las características de
varias rutas diferentes de forma que sólo es posible el anuncio de una sola. En este ejemplo, RTB genera la red 160.10.0.0. RTC se configura para
propagar una superred de dicha ruta 160.0.0.0 en RTA:
RTB#
router bgp 200
neighbor 3.3.3.1 remote-as 300
network 160.10.0.0
#RTC
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
network 170.10.0.0
aggregate-address 160.0.0.0 255.0.0.0
RTC propaga la dirección de agrupación 160.0.0.0 a RTA.
Comandos aggregate
Hay una amplia gama de comandos aggregate. Debe comprender cómo funcionan todos si desea conseguir el comportamiento adecuado de la
agrupación.
El primer comando se muestra en el ejemplo de la sección CIDR y direcciones de agrupación:
aggregate-address address-mask
Este comando anuncia la ruta del prefijo y las rutas más específicas. El comando aggregate-address 160.0.0.0 propaga una red adicional
160.0.0.0, pero no impide la propagación de 160.10.0.0 a RTA. El resultado es la propagación de las dos redes, 160.0.0.0 y 160.10.0.0, a RTA,
que es el anuncio de la ruta del prefijo y de la ruta más específica.
Nota: no puede agregar una dirección si no tiene una ruta más específica de dicha dirección en la tabla de enrutamiento BGP.
RTB no puede generar, por ejemplo, una agrupación para 160.0.0.0 si no tiene una entrada más específica de 160.0.0.0 en la tabla BGP. Se puede
efectuar una inyección de rutas más específicas en dicha tabla. La inyección de rutas puede tener lugar mediante:
Actualizaciones de entrada de otros AS.
La redistribución de un IGP o valor estático en BGP
El comando network, por ejemplo, network 160.10.0.0
Si desea que RTC propague solamente la red 160.0.0.0 y no la ruta más específica, ejecute el comando siguiente:
aggregate-address address mask summary-only
Este comando anuncia el prefijo solamente y suprime todas las rutas más específicas.
El comando aggregate 160.0.0.0 255.0.0.0. summary-only propaga la red 160.0.0.0 y suprime la ruta más específica 160.10.0.0.
Nota: si agrega una ruta que se inyectó en BGP por la sentencia network, la entrada de red se inyecta siempre en actualizaciones de BGP. Esta
inyección tiene lugar aunque use el comando aggregate summary-only. El ejemplo de la sección Ejemplo de CIDR 1 analiza esta situación.
aggregate-address address-mask as-set
Este comando anuncia la ruta del prefijo y las rutas más específicas. Pero el comando incluye as-set en la información de trayecto de las
actualizaciones de enrutamiento.
aggregate 129.0.0.0 255.0.0.0 as-set
La sección Ejemplo de CIDR 2 (as-set) analiza este comando.
Si desea suprimir rutas más específicas cuando efectúa la agrupación, defina una correspondencia de la ruta y aplíquela a las agrupaciones. Esta
acción permite seleccionar las rutas más específicas que se deben suprimir.
aggregate-address address-mask suppress-map map-name
Este comando anuncia la ruta del prefijo y las rutas más específicas. Pero el comando suprime el anuncio con una base de correspondencia de la
ruta. Supongamos que con el diagrama de la sección CIDR y direcciones de agrupación desea agregar 160.0.0.0, suprimir la ruta más específica
160.20.0.0 y permitir la propagación de 160.10.0.0. Use la correspondencia de la ruta siguiente:
route-map CHECK permit 10
match ip address 1
access-list 1 permit 160.20.0.0 0.0.255.255
access-list 1 deny 0.0.0.0 255.255.255.255
Por la definición de suppress-map, se suprime de las actualizaciones cualquier paquete que permita la lista de acceso.
A continuación, aplique la correspondencia de la ruta a la sentencia aggregate.
RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 remote-as 100
network 170.10.0.0
aggregate-address 160.0.0.0 255.0.0.0 suppress-map CHECK
Aquí tiene otra variación:
aggregate-address address-mask attribute-map map-name
Este comando permite definir los atributos, como la métrica, en el momento de enviar las agrupaciones. Para definir el origen de las agrupaciones
en IGP, aplique la correspondencia de la ruta siguiente al comando aggregate attribute-map:
route-map SETMETRIC
set origin igp
aggregate-address 160.0.0.0 255.0.0.0 attribute-map SETORIGIN
Si desea obtener más información, consulte Understanding Route Aggregation in BGP (Introducción a la agrupación de rutas en BGP).
Ejemplo de CIDR 1
Solicitud: permitir a RTB que anuncie el prefijo 160.0.0.0 y que suprima todas las rutas más específicas. El problema de esta solicitud es que la
red 160.10.0.0 es local de AS200, lo que significa que AS200 es quien la origina. No puede hacer que RTB genere un prefijo para 160.0.0.0 sin
generar una entrada para 160.10.0.0, aunque use el comando aggregate summary-only. RTB genera las dos redes porque RTB es quien origina
160.10.0.0. Hay dos soluciones para este problema.
La primera es usar una ruta estática y redistribuirla en BGP. El resultado es que RTB anuncia la agrupación con un origen incompleto (?).
RTB#
router bgp 200
neighbor 3.3.3.1 remote-as 300
redistribute static
!--- Genera una actualización para 160.0.0.0
!--- con el trayecto de origen como incompleto.
ip route 160.0.0.0 255.0.0.0 null0
En la segunda solución, además de la ruta estática, se agrega una entrada para el comando network. Esta entrada tiene el mismo efecto, con la
diferencia de que define el origen de la actualización en IGP.
RTB#
router bgp 200
network 160.0.0.0 mask 255.0.0.0
!--- Esta entrada marca la actualización con el origen IGP.
neighbor 3.3.3.1 remote-as 300
redistribute static
ip route 160.0.0.0 255.0.0.0 null0
Ejemplo de CIDR 2 (as-set)
Use la sentencia as-set en la agrupación para reducir el tamaño de la información de trayecto. Con as-set, el número de AS se enumera sólo una
vez, independientemente de la cantidad de veces que aparece en los múltiples trayectos agregados. El comando aggregate as-set se usa en
situaciones en las que la agrupación de la información provoca la pérdida de datos respecto al atributo de trayecto. En este ejemplo, RTC recibe
la actualización sobre 160.20.0.0 de RTA y actualiza 160.10.0.0 a partir de RTB. Supongamos que RTC desea agregar la red 160.0.0.0/8 y
enviarla a RTD. RTD desconoce el origen de dicha ruta. Si agrega la sentencia aggregate as-set, está obligando a RTC a generar información de
trayecto en la forma de un conjunto {}. Dicho conjunto incluye toda la información de trayecto, independientemente de cual fuera el primer
trayecto.
RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote-as 300
RTA#
router bgp 100
network 160.20.0.0
neighbor 2.2.2.1 remote-as 300
Caso 1:
RTC no tiene una sentencia as-set. RTC envía una actualización de 160.0.0.0/8 a RTD con la información de trayecto (300), como si la ruta se
hubiera originado desde AS300.
RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 4.4.4.4 remote-as 400
aggregate 160.0.0.0 255.0.0.0 summary-only
!--- Este comando hace que RTC envíe las actualizaciones de RTD de 160.0.0.0/8
!--- sin ninguna indicación de que 160.0.0.0 procede de dos AS diferentes.
!--- Esto puede crear bucles si RTD tiene una entrada de nuevo en AS100 o AS200.
Caso 2:
RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 4.4.4.4 remote-as 400
aggregate 160.0.0.0 255.0.0.0 summary-only
aggregate 160.0.0.0 255.0.0.0 as-set
!--- Este comando hace que RTC envíe las actualizaciones de RTD de 160.0.0.0/8
!--- con una indicación de que 160.0.0.0 pertenece a un conjunto {100 200}.
Los dos siguientes temas, Confederación de BGP y Reflectores de ruta, van destinados a proveedores de servicios de Internet (ISP) que desean un
control más exhaustivo de la explosión de pares BGP dentro de sus AS.
Confederación de BGP
La implementación de la confederación de BGP reduce la interconexión de iBGP dentro de un sistema autónomo (AS). El truco está en dividir un
AS en varios otros y asignar el grupo completo a una única confederación. Cada AS tiene su iBGP totalmente interconectado y conexiones a
otros AS dentro de la confederación. Aunque estos AS tienen pares eBGP en los AS incluidos en la confederación, intercambian enrutamientos
como si usaran iBGP. De esta forma, la confederación conserva la información sobre el salto siguiente, la métrica y la preferencia local. Para el
mundo exterior, la confederación parece como un único AS.
Para configurar una confederación BGP, use el comando siguiente:
bgp confederation identifier autonomous-system
El identificador de confederación es el número de AS del grupo de la confederación.
Si ejecuta este comando, se crean pares entre varios AS dentro de la confederación:
bgp confederation peers autonomous-system [autonomous-system]
A continuación se incluye un ejemplo de confederación:
Supongamos que tiene un AS500 que consta de nueve interlocutores BGP. También existen otros interlocutores que no son BGP, pero sólo hay
interés por los interlocutores BGP que tienen conexiones eBGP con otros AS. Si desea crear una interconexión de iBGP completa dentro de
AS500, necesita nueve conexiones pares para cada router. Necesita ocho pares iBGP y un par eBGP a AS externos.
Si usa la confederación, puede dividir AS500 en varios AS: AS50, AS60 y AS70. El AS recibe un identificador de confederación 500. El mundo
exterior sólo ve un AS, AS500. Para cada AS50, AS60 y AS70, puede definir una interconexión completa de pares iBGP y la lista de pares de
confederación con el comando bgp confederation peers.
A continuación se presenta una configuración de ejemplo de routers RTC, RTD y RTA:
Nota: RTA desconoce la existencia de AS50, AS60 y AS70. RTA sólo tiene conocimiento de AS500.
RTC#
router bgp 50
bgp confederation identifier 500
bgp confederation peers 60 70
neighbor 128.213.10.1 remote-as 50 (IBGP connection within AS50)
neighbor 128.213.20.1 remote-as 50 (IBGP connection within AS50)
neighbor 129.210.11.1 remote-as 60 (BGP connection with confederation peer 60)
neighbor 135.212.14.1 remote-as 70 (BGP connection with confederation peer 70)
neighbor 5.5.5.5 remote-as 100 (EBGP connection to external AS100)
RTD#
router bgp 60
bgp confederation identifier 500
bgp confederation peers 50 70
neighbor 129.210.30.2 remote-as 60 (IBGP connection within AS60)
neighbor 128.213.30.1 remote-as 50(BGP connection with confederation peer 50)
neighbor 135.212.14.1 remote-as 70 (BGP connection with confederation peer 70)
neighbor 6.6.6.6 remote-as 600 (EBGP connection to external AS600)
RTA#
router bgp 100
neighbor 5.5.5.4 remote-as 500 (EBGP connection to confederation 500)
Reflectores de ruta
Otra solución para la explosión de pares iBGP dentro de un AS son los reflectores de ruta (RR). Tal como demuestra la sección iBGP, un
interlocutor BGP no anuncia una ruta cuya existencia conoció por otro interlocutor iBGP a un tercer interlocutor iBGP. Puede relajar un poco esta
restricción y proporcionar control adicional, que permite a un router anunciar, o reflejar, las rutas cuyo conocimiento ha adquirido iBGP a otros
interlocutores iBGP. Este reflejo de ruta reduce el número de pares iBGP dentro de un AS.
En casos normales, mantenga una interconexión iBGP completa entre RTA, RTB y RTC dentro de AS100. Si usa el concepto RR, RTC se puede
elegir como un RR. De esta forma, RTC tiene un par parcial iBGP con RTA y RTB. Los pares entre RTA y RTB no son necesarios porque RTC
es un RR para las actualizaciones que proceden de RTA y RTB.
neighbor route-reflector-client
El router con este comando es el RR, y los vecinos a los que apunta el comando son los clientes de dicho RR. En el ejemplo, la configuración
RTC tiene el comando neighbor route-reflector-client que apunta a las direcciones IP de RTA y RTB. La combinación de RR y de clientes es
un "agrupamiento". En este ejemplo, RTA, RTB y RTC forman un agrupamiento con un único RR dentro de AS100.
Otros pares iBGP de RR que no son clientes son "no clientes".
Un AS puede tener más de un RR. En esta situación, un RR trata a otros RR como cualquier otro interlocutor iBGP. Otros RR pueden pertenecer
al mismo agrupamiento (grupo de clientes) o a otros. En una configuración sencilla, puede dividir el AS en varios agrupamientos. Cada RR se
configura con otros RR como pares no clientes en una topología completamente interconectada. Los clientes no deben crear pares con
interlocutores iBGP fuera del agrupamiento de clientes.
Considere este diagrama. RTA, RTB y RTC forman un único agrupamiento. RTC es el RR. Para RTC, RTA y RTB son clientes y todo lo demás
es un no cliente. Recuerde que el comando neighbor route-reflector-client señala a los clientes de un RR. El mismo RTD es el RR para clientes
RTE y RTF. RTG es un RR en un tercer agrupamiento.
Nota: RTD, RTC y RTG están completamente interconectados, pero los routers dentro del agrupamiento no lo están. Cuando un RR recibe una
ruta, efectúa el enrutamiento como se muestra en esta lista. Esta actividad depende, sin embargo, del tipo de par:
1. Rutas desde un par no cliente: refleja a todos los clientes dentro del agrupamiento.
2. Rutas desde un par cliente: refleja a todos los pares no clientes y también a los pares clientes.
3. Rutas desde un par eBGP: envía la actualización a todos los clientes y a los pares no clientes.
A continuación se presenta la configuración BGP relativa de los routers RTC, RTD y RTB:
RTC#
router bgp 100
neighbor 2.2.2.2
neighbor 2.2.2.2
neighbor 1.1.1.1
neighbor 1.1.1.1
neighbor 7.7.7.7
neighbor 4.4.4.4
neighbor 8.8.8.8
remote-as 100
route-reflector-client
remote-as 100
route-reflector-client
remote-as 100
remote-as 100
remote-as 200
RTB#
router bgp 100
neighbor 3.3.3.3 remote-as 100
neighbor 12.12.12.12 remote-as 300
RTD#
router bgp 100
neighbor 6.6.6.6
neighbor 6.6.6.6
neighbor 5.5.5.5
neighbor 5.5.5.5
neighbor 7.7.7.7
neighbor 3.3.3.3
remote-as 100
route-reflector-client
remote-as 100
route-reflector-client
remote-as 100
remote-as 100
Dado que hay un reflejo de las rutas conocidas de iBGP, puede haber un bucle de información de enrutamiento. El esquema RR dispone de
algunos métodos para evitar este bucle:
originator-id: es un atributo BGP opcional, no transitivo, que tiene una longitud de 4 bytes. Un RR crea este atributo. El atributo incorpora
el ID del router (RID) del creador de la ruta en el AS local. Si, debido a una configuración mal definida, la información de enrutamiento
vuelve al creador, ésta se pasa por alto.
cluster-list: la sección Varios RR dentro de un agrupamiento presenta la lista de agrupamientos.
Varios RR dentro de un agrupamiento
Generalmente, un agrupamiento de clientes tiene un único RR. En este caso, el ID del router del RR lo identifica. Para aumentar la redundancia y
evitar puntos de error, un agrupamiento puede tener más de un RR. Configure todos los RR del mismo agrupamiento con un ID de agrupamiento
de 4 bytes de modo que el RR pueda reconocer las actualizaciones en el mismo agrupamiento.
Una lista de agrupamientos es una secuencia de ID de agrupamiento que la ruta ha transferido. Cuando un RR refleja una ruta de clientes RR a no
clientes fuera del agrupamiento, el RR agrega el ID del agrupamiento local a la lista de agrupamientos. Si esta actualización tiene una lista de
agrupamientos vacía, el RR crea una. Con este atributo, un RR puede identificar si la información de enrutamiento ha creado un bucle al mismo
agrupamiento debido a una configuración incorrecta. Si el ID de agrupamiento local se encuentra en la lista de agrupamientos, el anuncio se
omite.
En el diagrama de esta sección, RTD, RTE, RTF y RTH pertenecen a un agrupamiento. RTD y RTH son RR para el mismo agrupamiento.
Nota: hay redundancia porque RTH tiene un par completamente interconectado con todos los RR. Si RTD no está activo, RTH toma su lugar.
A continuación se presenta la configuración de RTH, RTD, RTF y RTC:
RTH#
router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100
neighbor 9.9.9.9 remote-as 300
bgp cluster-id 10
RTD#
router bgp 100
neighbor 10.10.10.10 remote-as 100
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100
neighbor 11.11.11.11 remote-as 400
bgp cluster-id 10
RTF#
router bgp 100
neighbor 10.10.10.10 remote-as 100
neighbor 4.4.4.4 remote-as 100
neighbor 13.13.13.13 remote-as 500
RTC#
router bgp 100
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-reflector-client
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-reflector-client
neighbor 4.4.4.4 remote-as 100
neighbor 7.7.7.7 remote-as 100
neighbor 10.10.10.10 remote-as 100
neighbor 8.8.8.8 remote-as 200
Nota: no necesita el comando bgp cluster-id para RTC porque en dicho agrupamiento sólo hay un RR.
Nota importante: esta configuración no usa grupos de pares. No los emplee si los clientes de un agrupamiento no tienen pares iBGP directos
entre ellos y los clientes intercambian actualizaciones a través del RR. Si configura grupos de pares, un posible repliegue al origen de una ruta en
el RR se transmite a todos los clientes del agrupamiento. Esta transmisión puede producir problemas.
El subcomando bgp client-to-client reflection del router está habilitado de forma predeterminada en el RR. Si desactiva el reflejo cliente a
cliente de BGP en el RR y crea pares BGP redundantes entre los clientes, puede usar los grupos de pares de forma segura.
RR e interlocutores BGP convencionales
Un sistema autónomo (AS) puede tener interlocutores BGP que no comprendan el concepto de reflectores de ruta (RR). Este documento llama a
estos routers interlocutores BGP convencionales. El esquema de RR permite la coexistencia de dichos interlocutores. Estos routers pueden ser
miembros de un grupo de clientes o de un grupo de no clientes. Su existencia permite una migración fácil y gradual del actual modelo iBGP al
modelo RR. Puede empezar a crear agrupamiento si configura un único router como RR y hace que otros RR y otros clientes RR normales sean
pares iBGP. A continuación, puede crear más agrupamientos gradualmente.
En este diagrama, RTD, RTE y RTF tienen el concepto de reflejo de ruta. RTC, RTA y RTB son routers "convencionales". No puede
configurarlos como RR. Puede realizar una interconexión normal de iBGP entre estos routers y RTD. Más tarde, cuando esté listo para efectuar
una actualización, puede convertir RTC en RR con clientes RTA y RTB. Los clientes no tienen que comprender el esquema de reflejo de ruta,
sólo los RR requieren la actualización.
A continuación se presenta la configuración de RTD y RTC:
RTD#
router bgp 100
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 3.3.3.3 remote-as 100
neighbor 2.2.2.2 remote-as 100
neighbor 1.1.1.1 remote-as 100
neighbor 13.13.13.13 remote-as 300
RTC#
router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 2.2.2.2 remote-as 100
neighbor 1.1.1.1 remote-as 100
neighbor 14.14.14.14 remote-as 400
Cuando esté listo para efectuar una actualización de RTC y convertir RTC en RR, suprima la interconexión completa iBGP y haga que RTA y
RTB se conviertan en clientes de RTC.
Métodos para evitar el bucle de información de enrutamiento
Hasta el momento, en este documento se han mencionado dos atributos que puede usar para evitar un posible bucle de información: originator-id
y cluster-list.
Otra forma de controlar los bucles es añadir más restricciones en la cláusula set de correspondencias de la ruta de salida. Dicha cláusula set no
afecta a las rutas que reflejan a los pares iBGP.
También pueden poner más restricciones en nexthop-self, que es una opción de configuración por vecino. Cuando usa nexthop-self en los RR, la
cláusula sólo afecta al salto siguiente de las rutas conocidas de eBGP porque el salto siguiente de las rutas reflejadas no se debe cambiar.
Amortiguación de la inestabilidad de las rutas
La versión 11.0 del software Cisco IOS introdujo la amortiguación de rutas, que es un mecanismo para minimizar el impacto que producen
ciertas rutas inestables. La amortiguación de rutas reduce también la oscilación en la red. Puede definir criterios para identificar las rutas que se
comportan de forma incorrecta. Una ruta que es inestable recibe una penalización de 1000 por cada caso de inestabilidad. Cuando las
penalizaciones acumuladas llegan a un "límite de supresión" predefinido, se procede a la supresión del anuncio de ruta. La penalización se reduce
exponencialmente en función de un valor de "tiempo de mitad de vida" preconfigurado. Cuando las penalizaciones disminuyen por debajo de un
"límite de reutilización" predefinido, se procede a la anulación de la supresión del anuncio de ruta.
La amortiguación de rutas no se aplica a las rutas que son externas a un AS y cuyo conocimiento se ha adquirido mediante iBGP. De esta forma,
la amortiguación de rutas impide una penalización más elevada de los pares iBGP para rutas externas al AS.
La penalización se reduce a una frecuencia de 5 segundos. La anulación de la supresión de las rutas se produce con una frecuencia de 10
segundos. El router conserva la información de amortiguación hasta que la penalización es menor que la mitad del "límite de reutilización". En
este punto, el router la depura.
Inicialmente, y como valor predeterminado, la amortiguación está desactivada. Si hay necesidad, esta función puede habilitarse en un futuro
próximo como valor predeterminado. Los comandos siguientes controlan la amortiguación de rutas:
bgp dampening: activa la amortiguación.
no bgp dampening: desactiva la amortiguación.
bgp dampening half-life-time : cambia el valor de tiempo de mitad de vida.
Un comando que define todos los parámetros al mismo tiempo es:
bgp dampening half-life-time reuse suppress maximum-suppress-time
La lista siguiente detalla la sintaxis:
half-life-time : el intervalo es 1-45 minutos y el valor predeterminado actual, 15 minutos.
reuse-value : el intervalo es 1-20.000 y el valor predeterminado, 750.
suppress-value : el intervalo es 1-20.000 y el valor predeterminado, 2000.
max-suppress-time : la duración máxima para la supresión de una ruta. El intervalo es de 1-255 minutos y el valor predeterminado es 4
veces el valor de tiempo de mitad de vida.
RTB#
hostname RTB
interface Serial0
ip address 203.250.15.2 255.255.255.252
interface Serial1
ip address 192.208.10.6 255.255.255.252
router bgp 100
bgp dampening
network 203.250.15.0
neighbor 192.208.10.5 remote-as 300
RTD#
hostname RTD
interface Loopback0
ip address 192.208.10.174 255.255.255.192
interface Serial0/0
ip address 192.208.10.5 255.255.255.252
router bgp 300
network 192.208.10.0
neighbor 192.208.10.6 remote-as 100
La configuración de RTB establece la amortiguación de rutas con parámetros predeterminados. Si suponemos que el enlace de eBGP a RTD es
estable, la tabla BGP de RTB aparece como se indica a continuación:
RTB# show ip bgp
BGP table version is 24, local router ID is 203.250.15.2 Status codes: s
suppressed, d damped, h history, * valid, > best, i - internal Origin
codes: i - IGP, e - EGP, ? - incomplete
Network
*> 192.208.10.0
*> 203.250.15.0
Next Hop
192.208.10.5
0.0.0.0
Metric LocPrf Weight Path
0
0 300 i
0
32768 i
Para simular la inestabilidad de una ruta, ejecute el comando clear ip bgp 192.208.10.6 en RTD. La tabla BGP de RTD aparece como se indica a
continuación:
RTB# show ip bgp
BGP table version is 24, local router ID is 203.250.15.2 Status codes: s
suppressed, d damped, h history, * valid, > best, i - internal Origin
codes: i - IGP, e - EGP, ? - incomplete
Network
h 192.208.10.0
*> 203.250.15.0
Next Hop
192.208.10.5
0.0.0.0
Metric LocPrf Weight Path
0
0 300 i
0
32768 i
La entrada BGP para 192.208.10.0 se encuentra en un estado history. Esto indica que no tiene un mejor trayecto a la ruta, pero que todavía
hay información sobre inestabilidad.
RTB# show ip bgp 192.208.10.0
BGP routing table entry for 192.208.10.0 255.255.255.0, version 25
Paths: (1 available, no best path)
300 (history entry)
192.208.10.5 from 192.208.10.5 (192.208.10.174)
Origin IGP, metric 0, external
Dampinfo: penalty 910, flapped 1 times in 0:02:03
La ruta ha recibido una penalización por inestabilidad, pero todavía está por debajo del "límite de supresión". El valor predeterminado es 2000.
Todavía no se ha suprimido la ruta. Si se hace inestable algunas veces más, verá lo siguiente:
RTB# show ip bgp
BGP table version is 32, local router ID is 203.250.15.2 Status codes:
s suppressed, d damped, h history, * valid, > best, i - internal Origin codes:
i - IGP, e - EGP, ? - incomplete
Network
*d 192.208.10.0
*> 203.250.15.0
Next Hop
192.208.10.5
0.0.0.0
Metric LocPrf Weight Path
0
0 300 i
0
32768 i
RTB# show ip bgp 192.208.10.0
BGP routing table entry for 192.208.10.0 255.255.255.0, version 32
Paths: (1 available, no best path)
300, (suppressed due to dampening)
192.208.10.5 from 192.208.10.5 (192.208.10.174)
Origin IGP, metric 0, valid, external
Dampinfo: penalty 2615, flapped 3 times in 0:05:18 , reuse in 0:27:00
La ruta se ha amortiguado o suprimido y se volverá a usar cuando la penalización llegue al "valor de reutilización". En este caso, el valor de
reutilización es el valor predeterminado 750. La información de amortiguación se depura cuando la penalización es menor que la mitad del límite
de reutilización. En este caso, la depuración tiene lugar cuando la penalización es 375 (750/2=375). Los comandos siguientes muestran y borran
la información estadística de inestabilidad:
show ip bgp flap-statistics: muestra las estadísticas de inestabilidad para todos los trayectos.
show ip bgp flap-statistics regexp regular-expression : muestra las estadísticas de inestabilidad para todos los trayectos que se
corresponden con la expresión normal.
show ip bgp flap-statistics filter-list list : muestra las estadísticas de inestabilidad para todos los trayectos que superan el filtro.
show ip bgp flap-statistics A.B.C.D m.m.m.m : muestra las estadísticas de inestabilidad para una única entrada.
show ip bgp flap-statistics A.B.C.D m.m.m.m longer-prefix: muestra las estadísticas de inestabilidad para entradas más específicas.
show ip bgp neighbor [dampened-routes] | [flap-statistics] : muestra las estadísticas de inestabilidad para todos los trayectos de un
vecino.
clear ip bgp flap-statistics : borra las estadísticas de inestabilidad para todas las rutas.
clear ip bgp flap-statistics regexp regular-expression : borra las estadísticas de inestabilidad para todos los trayectos que se
corresponden con la expresión normal.
clear ip bgp flap-statistics filter-list list : borra las estadísticas de inestabilidad para todos los trayectos que superan el filtro.
clear ip bgp flap-statistics A.B.C.D m.m.m.m : borra las estadísticas de inestabilidad para una única entrada.
clear ip bgp A.B.C.D flap-statistics: borra las estadísticas de inestabilidad para todos los trayectos de un vecino.
Selección de un trayecto por parte de BGP
Ahora que ya se ha familiarizado con los atributos y la terminología de BGP, consulte BGP Best Path Selection Algorithm (Algoritmo de
selección del mejor trayecto BGP).
Estudios de casos de BGP 5
Ejemplo de diseño práctico
Esta sección contiene un ejemplo de diseño que muestra la configuración y las tablas de enrutamiento como aparecen en realidad en los routers de
Cisco.
En esta sección se muestra cómo crear esta configuración paso a paso y los problemas que pueden surgir durante el proceso. Cuando tenga un
sistema autónomo (AS) que se conecta a dos ISP mediante eBGP, ejecute siempre iBGP dentro del AS para tener un mejor control de las rutas.
En este ejemplo, iBGP se ejecuta dentro de AS100 entre RTA y RTB, y OSPF se ejecuta como IGP. Supongamos que se conecta a dos ISP,
AS200 y AS300. Esta es la primera ejecución de las configuraciones para todos los routers:
Nota: estas configuraciones no son las definitivas.
RTA#
hostname RTA
ip subnet-zero
interface Loopback0
ip address 203.250.13.41 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Serial0
ip address 128.213.63.1 255.255.255.252
router ospf 10
network 203.250.0.0 0.0.255.255 area 0
router bgp 100
network 203.250.13.0
network 203.250.14.0
neighbor 128.213.63.2 remote-as 200
neighbor 203.250.15.2 remote-as 100
neighbor 203.250.15.2 update-source Loopback0
RTF#
hostname RTF
ip subnet-zero
interface Ethernet0
ip address 203.250.14.2 255.255.255.0
interface Serial1
ip address 203.250.15.1 255.255.255.252
router ospf 10
network 203.250.0.0 0.0.255.255 area 0
RTB#
hostname RTB
ip subnet-zero
interface Serial0
ip address 203.250.15.2 255.255.255.252
interface Serial1
ip address 192.208.10.6 255.255.255.252
router ospf 10
network 203.250.0.0 0.0.255.255 area 0
router bgp 100
network 203.250.15.0
neighbor 192.208.10.5 remote-as 300
neighbor 203.250.13.41 remote-as 100
RTC#
hostname RTC
ip subnet-zero
interface Loopback0
ip address 128.213.63.130 255.255.255.192
interface Serial2/0
ip address 128.213.63.5 255.255.255.252
!
interface Serial2/1
ip address 128.213.63.2 255.255.255.252
router bgp 200
network 128.213.0.0
neighbor 128.213.63.1 remote-as 100
neighbor 128.213.63.6 remote-as 400
RTD#
hostname RTD
ip subnet-zero
interface Loopback0
ip address 192.208.10.174 255.255.255.192
interface Serial0/0
ip address 192.208.10.5 255.255.255.252
!
interface Serial0/1
ip address 192.208.10.2 255.255.255.252
router bgp 300
network 192.208.10.0
neighbor 192.208.10.1 remote-as 500
neighbor 192.208.10.6 remote-as 100
RTE#
hostname RTE
ip subnet-zero
interface Loopback0
ip address 200.200.10.1 255.255.255.0
interface Serial0
ip address 195.211.10.2 255.255.255.252
interface Serial1
ip address 128.213.63.6 255.255.255.252
clockrate 1000000
router bgp 400
network 200.200.10.0
neighbor 128.213.63.5 remote-as 200
neighbor 195.211.10.1 remote-as 500
RTG#
hostname RTG
ip subnet-zero
interface Loopback0
ip address 195.211.10.174 255.255.255.192
interface Serial0
ip address 192.208.10.1 255.255.255.252
interface Serial1
ip address 195.211.10.1 255.255.255.252
router bgp 500
network 195.211.10.0
neighbor 192.208.10.2 remote-as 300
neighbor 195.211.10.2 remote-as 400
Use siempre el comando network o redistribuya entradas estáticas en BGP para anunciar redes. Este método es mejor que redistribuir IGP en
BGP. En el ejemplo se usa el comando network para inyectar redes en BGP.
Aquí, se empieza con la interfaz s1 durante el cierre de RTB, como si el enlace entre RTB y RTD no existiera. La tabla BGP de RTB es como se
indica a continuación:
RTB# show ip bgp BGP
table version is 4, local router ID is 203.250.15.2 Status
codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric LocPrf Weight Path
*i128.213.0.0
128.213.63.2
0
100
0 200 i
*i192.208.10.0
128.213.63.2
100
0 200 400 500
300 i
*i195.211.10.0
128.213.63.2
100
0 200 400 500 i
*i200.200.10.0
128.213.63.2
100
0 200 400 i
*>i203.250.13.0
203.250.13.41
0
100
0 i
*>i203.250.14.0
203.250.13.41
0
100
0 i
*>203.250.15.0
0.0.0.0
0
32768 i
En esta tabla, aparecen las anotaciones siguientes:
Una i al principio: indica que un par iBGP ha dado a conocer la entrada.
Una i al final: indica que el origen de la información de trayecto es IGP.
Path: esta información es intuitiva. La red 128.213.0.0, por ejemplo, se ha dado a conocer mediante el trayecto 200 con un salto siguiente
de 128.213.63.2.
Nota: cualquier entrada generada localmente, como 203.250.15.0, tiene un salto siguiente 0.0.0.0.
Un >: indica que BGP ha elegido la mejor ruta. BGP usa los pasos de decisión que se detallan en el documento BGP Best Path Selection
Algorithm (Algoritmo de selección del mejor trayecto BGP). BGP selecciona el mejor trayecto para llegar a un destino, lo instala en la
tabla de enrutamiento de IP y lo anuncia a otros pares BGP.
Nota: observe el atributo Next Hop. RTB tiene conocimiento de 128.213.0.0 por un salto siguiente de 128.213.63.2, que es el salto
siguiente eBGP que se ejecuta en iBGP.
Consulte la tabla de enrutamiento de IP:
RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default
Gateway of last resort is not set
O
C
O
203.250.13.0 255.255.255.255 is subnetted, 1 subnets
203.250.13.41 [110/75] via 203.250.15.1, 02:50:45, Serial0
203.250.15.0 255.255.255.252 is subnetted, 1 subnets
203.250.15.0 is directly connected, Serial0
203.250.14.0 [110/74] via 203.250.15.1, 02:50:46, Serial0
Aparentemente, ninguna de las entradas BGP tiene acceso a ella. Hay dos problemas aquí:
El primero es que no se puede acceder al salto siguiente para estas entradas, 128.213.63.2. No hay forma alguna de tener acceso al salto siguiente
mediante este IGP, que es OSPF. RTB no ha obtenido conocimiento de 128.213.63.0 mediante OSPF. Puede ejecutar OSPF en la interfaz s0 de
RTA y hacerla pasiva; de esta forma, RTB sabe cómo puede tener acceso al salto siguiente 128.213.63.2. Esta configuración de RTA aparece
aquí:
RTA#
hostname RTA
ip subnet-zero
interface Loopback0
ip address 203.250.13.41 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Serial0
ip address 128.213.63.1 255.255.255.252
router ospf 10
passive-interface Serial0
network 203.250.0.0 0.0.255.255 area 0
network 128.213.0.0 0.0.255.255 area 0
router bgp 100
network 203.250.0.0 mask 255.255.0.0
neighbor 128.213.63.2 remote-as 200
neighbor 203.250.15.2 remote-as 100
neighbor 203.250.15.2 update-source Loopback0
Nota: puede ejecutar el comando bgp nexthopself entre RTA y RTB para cambiar el salto siguiente.
La nueva tabla BGP de RTB es como se indica a continuación:
RTB# show ip bgp
BGP table version is 10, local router ID is 203.250.15.2
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*>i128.213.0.0
*>i192.208.10.0
300 i
*>i195.211.10.0
*>i200.200.10.0
*>i203.250.13.0
*>i203.250.14.0
*> 203.250.15.0
Next Hop
128.213.63.2
128.213.63.2
128.213.63.2
128.213.63.2
203.250.13.41
203.250.13.41
0.0.0.0
Metric LocPrf Weight Path
0
100
0 200 i
100
0 200 400 500
0
0
0
100
100
100
100
0
0
0
0
32768
200 400 500 i
200 400 i
i
i
i
Nota: todas las entradas tienen >, lo que significa que BGP puede tener acceso al salto siguiente.
Consulte la tabla de enrutamiento:
RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is not set
O
C
O
O
203.250.13.0 255.255.255.255 is subnetted, 1 subnets
203.250.13.41 [110/75] via 203.250.15.1, 00:04:46, Serial0
203.250.15.0 255.255.255.252 is subnetted, 1 subnets
203.250.15.0 is directly connected, Serial0
203.250.14.0 [110/74] via 203.250.15.1, 00:04:46, Serial0
128.213.0.0 255.255.255.252 is subnetted, 1 subnets
128.213.63.0 [110/138] via 203.250.15.1, 00:04:47, Serial0
El segundo problema es que todavía no se ven las entradas BGP en la tabla de enrutamiento. La única diferencia es que ahora puede tener acceso
a 128.213.63.0 a través de OSPF. Se trata de un problema de sincronización. BGP no incorpora estas entradas en la tabla de enrutamiento y no las
envía en las actualizaciones de BGP por falta de sincronización con IGP.
Nota: RTF no tiene conocimiento de las redes 192.208.10.0 y 195.211.10.0 porque todavía no ha redistribuido BGP en OSPF.
En este escenario, si desactiva la sincronización, las entradas aparecen en la tabla de enrutamiento. Pero aún no hay conectividad.
Si desactiva la sincronización en RTB, ocurre lo siguiente:
RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is not set
B
B
B
O
B
C
O
B
O
200.200.10.0 [200/0] via 128.213.63.2, 00:01:07
195.211.10.0 [200/0] via 128.213.63.2, 00:01:07
192.208.10.0 [200/0] via 128.213.63.2, 00:01:07
203.250.13.0 is variably subnetted, 2 subnets, 2 masks
203.250.13.41 255.255.255.255
[110/75] via 203.250.15.1, 00:12:37, Serial0
203.250.13.0 255.255.255.0 [200/0] via 203.250.13.41, 00:01:08
203.250.15.0 255.255.255.252 is subnetted, 1 subnets
203.250.15.0 is directly connected, Serial0
203.250.14.0 [110/74] via 203.250.15.1, 00:12:37, Serial0
128.213.0.0 is variably subnetted, 2 subnets, 2 masks
128.213.0.0 255.255.0.0 [200/0] via 128.213.63.2, 00:01:08
128.213.63.0 255.255.255.252
[110/138] via 203.250.15.1, 00:12:37, Serial0
La tabla de enrutamiento parece correcta, pero no hay forma alguna de tener acceso a esas redes. RTF, situado en medio, no sabe cómo obtener
acceso a ellas:
RTF# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is not set
O
C
C
O
203.250.13.0 255.255.255.255 is subnetted, 1 subnets
203.250.13.41 [110/11] via 203.250.14.1, 00:14:15, Ethernet0
203.250.15.0 255.255.255.252 is subnetted, 1 subnets
203.250.15.0 is directly connected, Serial1
203.250.14.0 is directly connected, Ethernet0
128.213.0.0 255.255.255.252 is subnetted, 1 subnets
128.213.63.0 [110/74] via 203.250.14.1, 00:14:15, Ethernet0
Cuando se desactiva la sincronización en esta situación, el problema todavía existe. Sin embargo, la sincronización se necesitará más adelante
para otros temas. Redistribuya BGP en OSPF en RTA, con una métrica de 2000:
RTA#
hostname RTA
ip subnet-zero
interface Loopback0
ip address 203.250.13.41 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Serial0
ip address 128.213.63.1 255.255.255.252
router ospf 10
redistribute bgp 100 metric 2000 subnets
passive-interface Serial0
network 203.250.0.0 0.0.255.255 area 0
network 128.213.0.0 0.0.255.255 area 0
router bgp 100
network 203.250.0.0 mask 255.255.0.0
neighbor 128.213.63.2 remote-as 200
neighbor 203.250.15.2 remote-as 100
neighbor 203.250.15.2 update-source Loopback0
La tabla de enrutamiento es como se indica a continuación:
RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is not set
O E2 200.200.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
O E2 195.211.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
O E2 192.208.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O
203.250.13.41 255.255.255.255
[110/75] via 203.250.15.1, 00:00:15, Serial0
O E2
203.250.13.0 255.255.255.0
[110/2000] via 203.250.15.1, 00:00:15, Serial0
203.250.15.0 255.255.255.252 is subnetted, 2 subnets
C
203.250.15.8 is directly connected, Loopback1
C
203.250.15.0 is directly connected, Serial0
O
203.250.14.0 [110/74] via 203.250.15.1, 00:00:15, Serial0
128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2
128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1,
00:00:15,Serial0
O
128.213.63.0 255.255.255.252
[110/138] via 203.250.15.1, 00:00:16, Serial0
Las entradas BGP han desaparecido porque OSPF tiene una distancia mejor que iBGP. La distancia OSPF es 110, mientras que la distancia iBGP
es 200.
Desactive la sincronización en RTA de modo que pueda anunciar 203.250.15.0. Esta acción es necesaria porque RTA no sincroniza con OSPF
debido a la diferencia en máscaras. Mantenga la sincronización desactivada en RTB de modo que pueda anunciar 203.250.13.0. Esta acción es
necesaria en RTB por el mismo motivo.
Observemos ahora la interfaz s1 de RTB para ver cómo son las rutas. Habilite también OSPF en serie 1 de RTB para hacerlo pasivo. Este paso
permite a RTA tener conocimiento del salto siguiente 192.208.10.5 a través de IGP. Si lo omite, pueden producirse bucles de enrutamiento
porque para tener acceso al salto siguiente 192.208.10.5, debe ir por el otro camino a través de eBGP. A continuación se indican las nuevas
configuraciones de RTA y RTB:
RTA#
hostname RTA
ip subnet-zero
interface Loopback0
ip address 203.250.13.41 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Serial0
ip address 128.213.63.1 255.255.255.252
router ospf 10
redistribute bgp 100 metric 2000 subnets
passive-interface Serial0
network 203.250.0.0 0.0.255.255 area 0
network 128.213.0.0 0.0.255.255 area 0
router bgp 100
no synchronization
network 203.250.13.0
network 203.250.14.0
neighbor 128.213.63.2 remote-as 200
neighbor 203.250.15.2 remote-as 100
neighbor 203.250.15.2 update-source Loopback0
RTB#
hostname RTB
ip subnet-zero
interface Serial0
ip address 203.250.15.2 255.255.255.252
interface Serial1
ip address 192.208.10.6 255.255.255.252
router ospf 10
redistribute bgp 100 metric 1000 subnets
passive-interface Serial1
network 203.250.0.0 0.0.255.255 area 0
network 192.208.0.0 0.0.255.255 area 0
router bgp 100
no synchronization
network 203.250.15.0
neighbor 192.208.10.5 remote-as 300
neighbor 203.250.13.41 remote-as 100
La tabla BGP es como se indica a continuación:
RTA# show ip bgp
BGP table version is 117, local router ID is 203.250.13.41
Status codes: s suppressed, d damped, h history, * valid, > best,
i -internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*> 128.213.0.0
*>i192.208.10.0
*>i195.211.10.0
*
*> 200.200.10.0
*> 203.250.13.0
*> 203.250.14.0
*>i203.250.15.0
Next Hop
128.213.63.2
192.208.10.5
192.208.10.5
128.213.63.2
128.213.63.2
0.0.0.0
0.0.0.0
203.250.15.2
Metric LocPrf Weight Path
0
0 200
0
100
0 300
100
0 300
0 200
0 200
0
32768 i
0
32768 i
0
100
0 i
i
i
500 i
400 500 i
400 i
RTB# show ip bgp
BGP table version is 12, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best,
i -internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*>i128.213.0.0
*
200 i
*> 192.208.10.0
*> 195.211.10.0
*>i200.200.10.0
*
*>i203.250.13.0
*>i203.250.14.0
*> 203.250.15.0
Next Hop
128.213.63.2
192.208.10.5
192.208.10.5
192.208.10.5
128.213.63.2
192.208.10.5
203.250.13.41
203.250.13.41
0.0.0.0
Metric LocPrf Weight Path
0
100
0 200 i
0 300 500 400
0
100
0
0
0
100
100
0
0
0
0
0
0
32768
300
300
200
300
i
i
i
i
500 i
400 i
500 400 i
Hay varias formas de diseñar la red para que se comunique con dos ISP diferentes, AS200 y AS300. Una de ellas es tener un ISP principal y un
ISP de respaldo. Puede tener conocimiento de rutas parciales por uno de los ISP y asignar rutas predeterminadas a ambos. En este ejemplo, recibe
rutas parciales de AS200 y sólo rutas locales de AS300. RTA y RTB generan rutas predeterminadas en OSPF, con RTB como preferencia debido
a la métrica más baja. De esta forma, puede equilibrar el tráfico de salida entre los dos ISP.
Es posible que surja una asimetría si el tráfico que deja RTA vuelve por RTB. Esta situación puede ocurrir si usa el mismo agrupamiento de
direcciones IP, la misma red principal, cuando se comunica con los dos ISP. Debido a la agrupación, el mundo exterior verá el AS como una
entidad global. Los puntos de entrada a la red pueden tener lugar por RTA o RTB. Puede descubrir que todo el tráfico de entrada al AS llega por
un único punto, aunque disponga de múltiples puntos en Internet. En este ejemplo, tiene dos redes principales importantes cuando se comunica
con los dos ISP.
Otro motivo potencial para la asimetría es la diferencia en la longitud del trayecto anunciado para tener acceso al AS. Puede que un proveedor de
servicios esté más cercano a un determinado destino que otro. En este ejemplo, el tráfico de AS400 que tiene la red como destino siempre se
transfiere por RTA debido a que su trayecto es más corto. Puede intentar llevar a cabo dicha decisión. Utilice el comando set as-path prepend
para agregar números de trayecto a las actualizaciones y hacer que la longitud parezca más larga. Sin embargo, con atributos como preferencia
local, métrica o peso, AS400 puede haber establecido el punto de salida en AS200. En este caso, no hay nada que se pueda hacer.
Esta configuración es la configuración final para todos los routers:
RTA#
hostname RTA
ip subnet-zero
interface Loopback0
ip address 203.250.13.41 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Serial0
ip address 128.213.63.1 255.255.255.252
router ospf 10
redistribute bgp 100 metric 2000 subnets
passive-interface Serial0
network 203.250.0.0 0.0.255.255 area 0
network 128.213.0.0 0.0.255.255 area 0
default-information originate metric 2000
router bgp 100
no synchronization
network 203.250.13.0
network 203.250.14.0
neighbor 128.213.63.2
neighbor 128.213.63.2
neighbor 203.250.15.2
neighbor 203.250.15.2
remote-as 200
route-map setlocalpref in
remote-as 100
update-source Loopback0
ip classless
ip default-network 200.200.0.0
route-map setlocalpref permit 10
set local-preference 200
En RTA, la preferencia local para las rutas que proceden de AS200 se establece en 200. Además, la red 200.200.0.0 es la opción elegida como
candidata predeterminada. El comando ip default-network permite elegir el valor predeterminado.
Asimismo, en este ejemplo, el uso del comando default-information originate con OSPF inyecta la ruta predeterminada dentro del dominio
OSPF. Este ejemplo también emplea este comando con el protocolo Sistema intermedio a sistema intermedio (Protocolo IS-IS) y BGP. Para RIP,
hay una redistribución automática en RIP de 0.0.0.0, sin configuración adicional. Para IGRP y EIGRP, la inyección de la información
predeterminada en el dominio de IGP tiene lugar tras la redistribución de BGP en IGRP y EIGRP. Con IGRP y EIGRP, también puede
redistribuir una ruta estática de 0.0.0.0 en el ámbito de IGP.
RTF#
hostname RTF
ip subnet-zero
interface Ethernet0
ip address 203.250.14.2 255.255.255.0
interface Serial1
ip address 203.250.15.1 255.255.255.252
router ospf 10
network 203.250.0.0 0.0.255.255 area 0
ip classless
RTB#
hostname RTB
ip subnet-zero
interface Loopback1
ip address 203.250.15.10 255.255.255.252
interface Serial0
ip address 203.250.15.2 255.255.255.252
!
interface Serial1
ip address 192.208.10.6 255.255.255.252
router ospf 10
redistribute bgp 100 metric 1000 subnets
passive-interface Serial1
network 203.250.0.0 0.0.255.255 area 0
network 192.208.10.6 0.0.0.0 area 0
default-information originate metric 1000
!
router bgp 100
no synchronization
network 203.250.15.0
neighbor 192.208.10.5 remote-as 300
neighbor 192.208.10.5 route-map localonly in
neighbor 203.250.13.41 remote-as 100
!
ip classless
ip default-network 192.208.10.0
ip as-path access-list 1 permit ^300$
route-map localonly permit 10
match as-path 1
set local-preference 300
Para RTB, la preferencia local de las actualizaciones que proceden de AS300 se establece en 300. Este valor es superior al valor de preferencia
local de las actualizaciones de iBGP que proceden de RTA. De esta forma, AS100 selecciona RTB para las rutas locales de AS300. Cualquier
otra ruta de RTB, si la hay, se transmite internamente con una preferencia local de 100. Este valor es inferior a la preferencia local de 200, que
procede de RTA; por lo que RTA es la preferencia.
Nota: sólo se anuncian las rutas locales de AS300. Toda información de trayecto que no coincida con ^300$ se descarta. Si desea anunciar las
rutas locales y las rutas vecinas, que son los clientes de ISP, use ^300_[0-9]*.
A continuación se proporciona en el resultado de la expresión normal que indica las rutas locales de AS300:
RTB# show ip bgp regexp ^300$
BGP table version is 14, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*> 192.208.10.0
Next Hop
192.208.10.5
Metric LocPrf Weight Path
0
300
0 300
RTC#
hostname RTC
ip subnet-zero
interface Loopback0
ip address 128.213.63.130 255.255.255.192
interface Serial2/0
ip address 128.213.63.5 255.255.255.252
!
interface Serial2/1
ip address 128.213.63.2 255.255.255.252
router bgp 200
network 128.213.0.0
neighbor 128.213.63.1 remote-as 100
neighbor 128.213.63.1 distribute-list 1 out
neighbor 128.213.63.6 remote-as 400
ip classless
access-list 1 deny
195.211.0.0 0.0.255.255
access-list 1 permit any
En RTC, se agrega 128.213.0.0/16 y se indican las rutas específicas para inyección en AS100. Si el ISP se niega a efectuar esta tarea, se deberá
filtrar el extremo de entrada de AS100.
RTD#
hostname RTD
ip subnet-zero
interface Loopback0
ip address 192.208.10.174 255.255.255.192
!
interface Serial0/0
ip address 192.208.10.5 255.255.255.252
!
interface Serial0/1
ip address 192.208.10.2 255.255.255.252
router bgp 300
network 192.208.10.0
neighbor 192.208.10.1 remote-as 500
neighbor 192.208.10.6 remote-as 100
RTG#
hostname RTG
ip subnet-zero
interface Loopback0
ip address 195.211.10.174 255.255.255.192
interface Serial0
ip address 192.208.10.1 255.255.255.252
interface Serial1
ip address 195.211.10.1 255.255.255.252
router bgp 500
network 195.211.10.0
aggregate-address 195.211.0.0 255.255.0.0 summary-only
neighbor 192.208.10.2 remote-as 300
neighbor 192.208.10.2 send-community
neighbor 192.208.10.2 route-map setcommunity out
neighbor 195.211.10.2 remote-as 400
!
ip classless
access-list 1 permit 195.211.0.0 0.0.255.255
access-list 2 permit any
route-map setcommunity permit 20
match ip address 2
!
route-map setcommunity permit 10
match ip address 1
set community no-export
En RTG se encuentra la demostración del uso de los filtros de la comunidad. Se agrega una comunidad no-export a las actualizaciones de
195.211.0.0 hacia RTD. De esta forma, RTD no exporta dicha ruta a RTB. En este caso, sin embargo, RTB tampoco acepta estas rutas.
RTE#
hostname RTE
ip subnet-zero
interface Loopback0
ip address 200.200.10.1 255.255.255.0
interface Serial0
ip address 195.211.10.2 255.255.255.252
interface Serial1
ip address 128.213.63.6 255.255.255.252
router bgp 400
network 200.200.10.0
aggregate-address 200.200.0.0 255.255.0.0 summary-only
neighbor 128.213.63.5 remote-as 200
neighbor 195.211.10.1 remote-as 500
ip classless
RTE agrega 200.200.0.0/16. Aquí se presentan las tablas finales de enrutamiento y BGP para RTA, RTF y RTB:
RTA# show ip bgp
BGP table version is 21, local router ID is 203.250.13.41
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*> 128.213.0.0
*>i192.208.10.0
*> 200.200.0.0/16
*> 203.250.13.0
*> 203.250.14.0
*>i203.250.15.0
Next Hop
128.213.63.2
192.208.10.5
128.213.63.2
0.0.0.0
0.0.0.0
203.250.15.2
Metric LocPrf Weight Path
0
200
0 200 i
0
300
0 300 i
200
0 200 400 i
0
32768 i
0
32768 i
0
100
0 i
RTA# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is 128.213.63.2 to network 200.200.0.0
192.208.10.0 is variably subnetted, 2 subnets, 2 masks
O E2
192.208.10.0 255.255.255.0
[110/1000] via 203.250.14.2, 00:41:25, Ethernet0
O
192.208.10.4 255.255.255.252
[110/138] via 203.250.14.2, 00:41:25, Ethernet0
C
203.250.13.0 is directly connected, Loopback0
203.250.15.0 is variably subnetted, 3 subnets, 3 masks
O
203.250.15.10 255.255.255.255
[110/75] via 203.250.14.2, 00:41:25, Ethernet0
O
203.250.15.0 255.255.255.252
[110/74] via 203.250.14.2, 00:41:25, Ethernet0
B
203.250.15.0 255.255.255.0 [200/0] via 203.250.15.2, 00:41:25
C
203.250.14.0 is directly connected, Ethernet0
128.213.0.0 is variably subnetted, 2 subnets, 2 masks
B
128.213.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:41:26
C
128.213.63.0 255.255.255.252 is directly connected, Serial0
O*E2 0.0.0.0/0 [110/1000] via 203.250.14.2, Ethernet0/0
B*
200.200.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:02:38
RTF# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is 203.250.15.2 to network 0.0.0.0
192.208.10.0 is variably subnetted, 2 subnets, 2 masks
O E2
192.208.10.0 255.255.255.0
[110/1000] via 203.250.15.2, 00:48:50, Serial1
O
192.208.10.4 255.255.255.252
[110/128] via 203.250.15.2, 01:12:09, Serial1
203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O
203.250.13.41 255.255.255.255
[110/11] via 203.250.14.1, 01:12:09, Ethernet0
O E2
203.250.13.0 255.255.255.0
[110/2000] via 203.250.14.1, 01:12:09, Ethernet0
203.250.15.0 is variably subnetted, 2 subnets, 2 masks
O
203.250.15.10 255.255.255.255
[110/65] via 203.250.15.2, 01:12:09, Serial1
C
203.250.15.0 255.255.255.252 is directly connected, Serial1
C
203.250.14.0 is directly connected, Ethernet0
128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2
128.213.0.0 255.255.0.0
[110/2000] via 203.250.14.1, 00:45:01, Ethernet0
O
128.213.63.0 255.255.255.252
[110/74] via 203.250.14.1, 01:12:11, Ethernet0
O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.14.1, 00:03:47,
Ethernet0
O*E2 0.0.0.0 0.0.0.0 [110/1000] via 203.250.15.2, 00:03:33, Serial1
Nota: la tabla de enrutamiento RTF indica que la forma de tener acceso a redes locales de AS300, como 192.208.10.0, es a través de RTB. La
forma de poder conectarse a otras redes conocidas, como 200.200.0.0, es a través de RTA. La gateway del último recurso se establece en RTB. Si
hay algún problema con la conexión entre RTB y RTD, el valor predeterminado que RTA anuncia se inicia con una métrica de 2000.
RTB# show ip bgp
BGP table version is 14, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*>i128.213.0.0
*> 192.208.10.0
*>i200.200.0.0/16
*>i203.250.13.0
*>i203.250.14.0
*> 203.250.15.0
Next Hop
128.213.63.2
192.208.10.5
128.213.63.2
203.250.13.41
203.250.13.41
0.0.0.0
Metric LocPrf Weight Path
0
200
0 200 i
0
300
0 300 i
200
0 200 400 i
0
100
0 i
0
100
0 i
0
32768 i
RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is 192.208.10.5 to network 192.208.10.0
*
B*
C
192.208.10.0 is variably subnetted, 2 subnets, 2 masks
192.208.10.0 255.255.255.0 [20/0] via 192.208.10.5, 00:50:46
192.208.10.4 255.255.255.252 is directly connected, Serial1
203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O
203.250.13.41 255.255.255.255
[110/75] via 203.250.15.1, 01:20:33, Serial0
O E2
203.250.13.0 255.255.255.0
[110/2000] via 203.250.15.1, 01:15:40, Serial0
203.250.15.0 255.255.255.252 is subnetted, 2 subnets
C
203.250.15.8 is directly connected, Loopback1
C
203.250.15.0 is directly connected, Serial0
O
203.250.14.0 [110/74] via 203.250.15.1, 01:20:33, Serial0
128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2
128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:46:55, Serial0
O
128.213.63.0 255.255.255.252
[110/138] via 203.250.15.1, 01:20:34, Serial0
O*E2 0.0.0.0/0 [110/2000] via 203.250.15.1, 00:08:33, Serial0
O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:05:42, Serial0
© 1992-2014 Cisco Systems Inc. Todos los Derechos Reservados.
Fecha de Generación del PDF: 23 Junio 2008
http://www.cisco.com/cisco/web/support/LA/7/76/76167_bgp-toc.html