Funcionamiento de BGP en equipos Cisco

Estudios de casos de BGP

ContenidosIntroducción Requisitos previos Requisitos Componentes utilizados ConvencionesEstudios 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 BGPEstudios 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 comunidadEstudios de casos de BGP 3 Filtrado de BGP Expresión normal de AS Vecinos y correspondencias de la ruta BGPEstudios 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 BGPEstudios de casos de BGP 5 Ejemplo de diseño práctico

IntroducciónEste 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 lasconvenciones del documento.

Estudios de casos de BGP 1El BGP, que se define en RFC 1771 , permite crear enrutamientos interdominio sin bucles entre sistemas autónomos (AS). Un sistemaautó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 routerspares, 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 trayectoscompletos 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 ungráfico de los AS sin bucles. El gráfico muestra también dónde deben aplicarse las políticas de enrutamiento para imponer algunas restriccionesen 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 paresBGP intercambian inicialmente las tablas completas de enrutamiento BGP. Tras este intercambio, envían actualizaciones incrementales a medidaque 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 lospares 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ñalde mantenimiento garantiza que la conexión entre los pares BGP se mantenga activa. Los paquetes de notificación se generan en respuesta aerrores 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 eldiagrama 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, seejecutan 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 entrerouters 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 enAS diferentes. En el segundo, los dos routers pertenecen al mismo AS.

Defina el proceso de enrutamiento y el número de AS al que pertenecen los routers.1.

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.

Defina los vecinos BGP.2.

La formación de vecinos BGP identifica los routers que intentarán conectarse mediante BGP. En la sección Formación de vecinos BGP seexplica 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 routerspares 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, laversió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, seestablece la conexión con el vecino. Cualquier estado diferente a Established indica que los dos routers no se han convertido en vecinos yque 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 conconexió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 laaccesibilidad es efectuar un ping ampliado entre las dos direcciones IP. El ping ampliado obliga al router que hace ping a usar como origen ladirecció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 elpaquete.

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 tenganefecto.

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 haciaversiones anteriores. Puede impedir las negociaciones e imponer la versión de BGP que usan los routers para comunicarse con un vecino. Ejecuteel 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 100neighbor 129.213.1.1 remote-as 200

RTB#router bgp 200neighbor 129.213.1.2 remote-as 100neighbor 175.220.1.2 remote-as 200

RTC#router bgp 200neighbor 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 indicaeBGP o iBGP. Además, los pares eBGP tienen conexión directa, pero los pares iBGP no. Los routers iBGP no la necesitan. Sin embargo, debehaber 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 buclede 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 deeBGP, 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 routervecino 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 BGPvecino. 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 1RTB# 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.1update-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 con190.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 elque 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 delescenario 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 paresexternos. Para conseguir la conexión, puede usar el eBGP de varios saltos. El eBGP de varios saltos permite una conexión vecina entre dos paresexternos 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 devarios saltos:

RTA#router bgp 100neighbor 180.225.11.1 remote-as 300neighbor 180.225.11.1 ebgp-multihopRTB#router bgp 300neighbor 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 indicaun 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éndeberí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 detener eBGP en líneas paralelas.

eBGP de varios saltos (balance de carga)

RTA#int loopback 0ip address 150.10.1.1 255.255.255.0router bgp 100neighbor 160.10.1.1 remote-as 200neighbor 160.10.1.1 ebgp-multihopneighbor 160.10.1.1 update-source loopback 0network 150.10.0.0

ip route 160.10.0.0 255.255.0.0 1.1.1.2ip route 160.10.0.0 255.255.0.0 2.2.2.2RTB#int loopback 0ip address 160.10.1.1 255.255.255.0router bgp 200neighbor 150.10.1.1 remote-as 100neighbor 150.10.1.1 update-source loopback 0neighbor 150.10.1.1 ebgp-multihopnetwork 160.10.0.0

ip route 150.10.0.0 255.255.0.0 1.1.1.1ip 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 paraconseguir el balance de carga entre dos interlocutores eBGP en líneas de serie paralelas. En situaciones normales, BGP selecciona una de laslí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 saltopara eBGP es la interfaz de bucle de retorno. Se usan rutas estáticas o un IGP para introducir dos trayectos de igual costo para conseguircomunicarse 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 mediante2.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ónde enrutamiento. El control y la modificación de la información de enrutamiento se efectúan mediante la definición de condiciones para laredistribució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 mismacorrespondencia o la misma etiqueta de nombre. El número de secuencia indica la posición que debe tener una nueva correspondencia de la rutaen 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 secuenciade 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 lainstancia 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 elsegundo 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ónset. 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 lalista.

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 laruta. Se verifica, por ejemplo, la instancia 20. Esta verificación de la siguiente instancia continúa hasta que se encuentra fuera o finaliza todas lasinstancias 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 BGPen 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 sepuede 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 lasactualizaciones 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 de2 y el resto de rutas con una métrica de 5. En este caso, puede usar la configuración siguiente:

RTA#router ripnetwork 3.0.0.0network 2.0.0.0network 150.10.0.0passive-interface Serial0redistribute bgp 100 route-map SETMETRIC

router bgp 100neighbor 2.2.2.3 remote-as 300network 150.10.0.0

route-map SETMETRIC permit 10match ip-address 1set metric 2

route-map SETMETRIC permit 20set 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 decorrespondencias 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étrica5.

Nota: hágase siempre la pregunta "¿Qué ocurre a las rutas que no concuerdan con ninguna sentencia de coincidencia?". De formapredeterminada, 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 lasalida 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 300network 170.10.0.0neighbor 2.2.2.2 remote-as 100neighbor 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.255access-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 seefectúa con el Protocolo de enrutamiento de gateway interior (IGRP) y RIP. Con este comando, el usuario no intenta ejecutar BGP en unadeterminada interfaz. En su lugar, intenta indicar a BGP las redes BGP que se deben originar desde este recuadro. El comando usa una porción demá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 sehaya adquirido de forma dinámica.

Un ejemplo del comando network es:

RTA#router bgp 1network 192.213.0.0 mask 255.255.0.0ip 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 yque 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 deenrutamiento.

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, elprotocolo 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 deestas 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 rutasque 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 10network 175.220.0.0redistribute bgp 200default-metric 1000 100 250 100 1500

router bgp 200neighbor 1.1.1.1 remote-as 300network 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:


router bgp 200neighbor 1.1.1.1 remote-as 300redistribute 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 queel AS sea el origen de dicha red. La configuración correcta es la siguiente:


router bgp 200neighbor 1.1.1.1 remote-as 300neighbor 1.1.1.1 distribute-list 1 outredistribute eigrp 10


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 enrouter bgp no funciona. Determinadas palabras clave como internal, external y nssa-external son necesarias para redistribuir las rutasrespectivas. 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 unorigen incompleto o desconocido. Puede conseguir el mismo resultado que en el ejemplo de la sección Redistribución con:


router bgp 200neighbor 1.1.1.1 remote-as 300redistribute 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 que175.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 otrasrutas BGP cuyo conocimiento ha adquirido BGP a través de vecinos, ya sean internos o externos. BGP transfiere la información que BGP haadquirido 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 100neighbor 150.10.20.2 remote-as 300network 150.10.0.0

RTB#router bgp 200neighbor 160.10.20.2 remote-as 300network 160.10.0.0

RTC#router bgp 300neighbor 150.10.20.1 remote-as 100neighbor 160.10.20.1 remote-as 200network 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 comollegan desde AS100 y AS200. La diferencia vuelve a ser que el comando network agrega un anuncio adicional para estas mismas redes, lo queindica 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íainterdominio 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.0y 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 AS100cuando 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 deltrá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 unmétodo mucho más eficiente para intercambiar información dentro de un AS. iBGP ofrece métodos, por ejemplo, para controlar el mejor puntode salida del AS con el uso de la preferencia local. La sección Atributo de preferencia local proporciona más información sobre la preferencialocal.

RTA#router bgp 100neighbor 190.10.50.1 remote-as 100neighbor 170.10.20.2 remote-as 300network 150.10.0.0

RTB#router bgp 100neighbor 150.10.30.1 remote-as 100neighbor 175.10.40.1 remote-as 400network 190.10.50.0

RTC#router bgp 400neighbor 175.10.40.2 remote-as 100network 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 interlocutorBGP que recibe la actualización no redistribuye esa información a otros interlocutores de su AS. El interlocutor BGP que la recibe redistribuye lainformación a otros interlocutores BGP fuera del AS. Por lo tanto, mantiene una interconexión completa entre los interlocutores iBGP dentro deun 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 deRTB y tienen como destino RTA se transmiten a RTE, que está fuera del AS. Las actualizaciones no se transmiten a RTD, que está dentro delAS. 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 trayectospara 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 deltrayecto, 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 trayectoBGP) 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 atributoAS_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 {} ordenadomatemáticamente de todos los AS que se han atravesado. La sección Ejemplo de CIDR 2 (as-set) de este documento ofrece un ejemplo deAS_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 deAS 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, eltrayecto 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 teneracceso 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 seejecuta 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 seredistribuyen rutas desde otros protocolos de enrutamiento en BGP y el origen de la ruta es incompleto. Una ? en la tabla BGP indicaINCOMPLETE.

RTA#router bgp 100neighbor 190.10.50.1 remote-as 100neighbor 170.10.20.2 remote-as 300network 150.10.0.0redistribute static

ip route 190.10.0.0 255.255.0.0 null0

RTB#router bgp 100neighbor 150.10.30.1 remote-as 100network 190.10.50.0RTE#router bgp 300neighbor 170.10.20.1 remote-as 100network 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. RTAtambié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 accesoa 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, RTCanuncia 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. ParaiBGP, 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 asu 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 es170.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 porqueno 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 RTA170.10.0.0. iGRP debería ser pasivo en el enlace a RTC de forma que sólo se intercambie BGP.

RTA#router bgp 100neighbor 170.10.20.2 remote-as 300neighbor 150.10.50.1 remote-as 100network 150.10.0.0RTB#router bgp 100neighbor 150.10.30.1 remote-as 100RTC#router bgp 300neighbor 170.10.20.1 remote-as 100network 170.10.0.0

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 siguientede 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 de170.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 supropia 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 quehace 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, elcomportamiento 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 300neighbor 170.10.20.1 remote-as 100neighbor 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 otroprotocolo. Por definición, las actualizaciones de eBGP tienen una distancia de 20, que es menor que las distancias de IGP. Las distanciaspredeterminadas 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 asignadalocalmente, a excepción de que las actualizaciones BGP no la anuncian.

RTA#router eigrp 10

network 150.10.0.0

router bgp 100neighbor 2.2.2.1 remote-as 300network 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 deRTC 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 ejecutaniBGP, 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 saltosiguiente 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 de170.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 destino170.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 losrouters del AS tengan conocimiento de ella mediante IGP. BGP espera hasta que IGP ha propagado la ruta dentro del AS. A continuación, BGPanuncia 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 laactualizació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 a170.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 puedeinhabilitarla si todos los routers del AS ejecutan BGP. La inhabilitación de esta función permite incorporar menos rutas en su IGP y que BGPconfluya 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 esperaindefinidamente una actualización de IGP de una determinada ruta antes de enviar la ruta a pares externos. En este caso, debe inhabilitar lasincronización manualmente para que el enrutamiento pueda funcionar correctamente:

router bgp 100no synchronization

Nota: asegúrese de ejecutar el comando clear ip bgp address para restablecer la sesión.

RTB#router bgp 100network 150.10.0.0neighbor 1.1.1.2 remote-as 400neighbor 3.3.3.3 remote-as 100no 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 400neighbor 1.1.1.1 remote-as 100network 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. Elvalor 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 unnú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. RTAha obtenido conocimiento de 175.10.0.0 mediante AS4. RTA propaga la actualización a RTC. RTB también ha obtenido conocimiento de175.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 elcamino 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 queproceden 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 estadefinició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-list-number weight weight

Use correspondencias de la ruta.

RTC#router bgp 300neighbor 1.1.1.1 remote-as 100neighbor 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 200neighbor 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 300neighbor 1.1.1.1 remote-as 100neighbor 1.1.1.1 filter-list 5 weight 200neighbor 2.2.2.2 remote-as 200neighbor 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 300neighbor 1.1.1.1 remote-as 100neighbor 1.1.1.1 route-map setweightin inneighbor 2.2.2.2 remote-as 200neighbor 2.2.2.2 route-map setweightin in...ip as-path access-list 5 permit ^100$...

route-map setweightin permit 10match as-path 5set 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 unadeterminada 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 routersintercambian 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 conlas 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 elmismo AS. En el diagrama de esta sección, AS256 recibe actualizaciones de 170.10.0.0 desde dos puntos distintos de la organización. Lapreferencia local ayuda a determinar el camino de salida de AS256 para alcanzar dicha red. Supongamos que RTD es la preferencia de punto desalida. Esta configuración define la preferencia local para las actualizaciones que proceden de AS300 hacia 200 y para las actualizaciones queproceden de AS100 hacia 150:

RTC#router bgp 256neighbor 1.1.1.1 remote-as 100neighbor 128.213.11.2 remote-as 256bgp default local-preference 150

RTD#router bgp 256neighbor 3.3.3.4 remote-as 300neighbor 128.213.11.1 remote-as 256bgp 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 lasactualizaciones en 200. Hay un intercambio de preferencia local dentro de AS256. Por consiguiente, tanto RTC como RTD se dan cuenta de quela red 170.10.0.0 tiene una preferencia local superior cuando las actualizaciones proceden de AS300 en lugar de AS100. Todo el tráfico enAS256 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 seetiquetan con la preferencia local 200 cuando llegan a RTD. Las actualizaciones que proceden de AS34 también se etiquetan con la preferencialocal de 200, etiqueta que puede que no sea necesaria. Por este motivo, puede usar correspondencias de la ruta para especificar las actualizacionesque se deben etiquetar con una determinada preferencia local. A continuación se proporciona un ejemplo:

RTD#router bgp 256neighbor 3.3.3.4 remote-as 300neighbor 3.3.3.4 route-map setlocalin inneighbor 128.213.11.1 remote-as 256....ip as-path access-list 7 permit ^300$...

route-map setlocalin permit 10match as-path 7set local-preference 200

route-map setlocalin permit 20set local-preference 150

Con esta configuración, cualquier actualización procedente de AS300 tiene una preferencia local de 200. Cualquier otra, por ejemplo, lasprocedentes 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 paralos vecinos externos sobre la preferencia de trayecto en un sistema autónomo (AS). El atributo ofrece una forma dinámica de influir en otro ASpara 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. Cuandouna 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 mismaactualizació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 valorpredeterminado 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 routercompare las métricas de los vecinos que proceden de diferentes AS, debe ejecutar el comando de configuración especial bgp always-compare-med 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 garantizala 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 bgpalways-compare-med, se garantiza la comparación de MED para los trayectos de vecinos en diferentes AS. El comando bgp always-compare-med es de utilidad cuando múltiples proveedores de servicios o empresas acuerdan una política uniforme para configurar MED. Consulte Howthe bgp deterministic-med Command Differs from the bgp always-compare-med Command (En qué se diferencia el comando bgp deterministic-med 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 RTDestá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. Demanera predeterminada, un router compara la métrica que procede de los vecinos en el mismo AS. Por lo tanto, RTA sólo puede comparar lamé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 ASdiferentes. 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 siguientesmuestran 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


RTB# router bgp 400 neighbor 4.4.4.4 remote-as 100 neighbor 4.4.4.4 route-map setmetricout out


Con estas configuraciones, RTA selecciona a RTC como salto siguiente, porque se considera que todos los otros atributos son iguales. Paraincluir RTB en la comparación de la métrica, debe configurar RTA de la forma siguiente:

RTA#router bgp 100neighbor 2.2.21 remote-as 300neighbor 3.3.3.3 remote-as 300neighbor 4.4.4.3 remote-as 400bgp 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 400redistribute staticdefault-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 destinosen una determinada comunidad y de aplicar decisiones de enrutamiento según estas comunidades. Las decisiones de enrutamiento son, entreotras, 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 lasintaxis 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 1set community no-advertise

o

route-map setcommunitymatch as-path 1set 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 unaadición de 200 a la comunidad. Aunque defina el atributo de comunidad, éste no se transmite a los vecinos de forma predeterminada. Paraenviarlo a un vecino, debe usar el comando siguiente:

neighbor {ip-address | peer-group-name} send-community


RTA#router bgp 100neighbor 3.3.3.3 remote-as 300neighbor 3.3.3.3 send-communityneighbor 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 yAA:NN. De forma predeterminada, el software Cisco IOS usa el formato decimal anterior. Para configurar y mostrar en formato AA:NN, ejecuteel 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, unnúmero de 2 bytes.


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 delatributo de comunidad en formato decimal. En este ejemplo, el valor del atributo de comunidad aparece como 6553620.

Router# show ip bgp 6.0.0.0BGP routing table entry for 6.0.0.0/8, version 7Paths: (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 terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip bgp-community new-formatRouter(config)# exit

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 semuestra 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.0BGP routing table entry for 6.0.0.0/8, version 9Paths: (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


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 BGPcon información de ruta como base, o con información de trayecto o de comunidades como base. Todos los métodos consiguen los mismosresultados. 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 deenrutamiento a o desde un determinado vecino. Puede definir una lista de acceso y aplicarla a las actualizaciones que proceden o que estándestinadas 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 actualizacionesa AS100, debe definir una lista de acceso para filtrar dichas actualizaciones y aplicarla durante la comunicación con RTA:

RTC#router bgp 300network 170.10.0.0neighbor 3.3.3.3 remote-as 200neighbor 2.2.2.2 remote-as 100neighbor 2.2.2.2 distribute-list 1 out

access-list 1 deny 160.10.0.0 0.0.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 anunciarsolamente 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 equivalentea 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/8solamente, 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 deconfiguraciones 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 deesta 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 enRTC 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 300neighbor 3.3.3.3 remote-as 200neighbor 2.2.2.2 remote-as 100neighbor 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 terminecon 200. ^200$ en el comando es una "expresión normal", en la que ^ significa "empieza por" y $ significa "termina por". Dado que RTB envíaactualizaciones de 160.10.0.0 con información de trayecto que comienza con 200 y termina con 200, las actualizaciones coinciden con la lista deacceso. 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 AS400tienen información de trayecto del tipo (200, 400). En esta información de trayecto, 200 es el primero y 400, el último. Estas actualizacionesconcuerdan con la lista de acceso ^200 porque la información de trayecto empieza por 200. La lista de acceso impide la transmisión de estasactualizaciones 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 comandomuestra 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 unaentrada.

En el ejemplo de la sección Filtrado de trayecto, especificó la cadena ^200$. Deseaba que la información de trayecto que incorporan lasactualizaciones 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 deexpresiones 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 decomunidad 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 paresexternos. Use el atributo de comunidad no-export.

RTB#router bgp 200network 160.10.0.0neighbor 3.3.3.1 remote-as 300neighbor 3.3.3.1 send-communityneighbor 3.3.3.1 route-map setcommunity out

route-map setcommunitymatch ip address 1set community no-export


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 decomunidad 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 setcommunitymatch ip address 2set community 100 200 additive


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 decomunidades 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-communitymatch community 10

!--- El número de la lista de comunidades es 10.

set weight 20ip 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 lacomunidad como base. En el segundo ejemplo de esta sección, RTB envía actualizaciones a RTC con una comunidad de 100 200. Si RTC deseadefinir el peso con dichos valores como base, puede hacer lo siguiente:

RTC#router bgp 300neighbor 3.3.3.3 remote-as 200neighbor 3.3.3.3 route-map check-community in

route-map check-community permit 10match community 1set weight 20

route-map check-community permit 20match community 2 exactset weight 10

route-map check-community permit 30match community 3

ip community-list 1 permit 100ip community-list 2 permit 200ip 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. Cualquierruta que tenga solamente 200 como comunidad, coincide con la lista 2 y tiene un peso de 20. La palabra clave exact indica que la comunidadconsta 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 sonmiembros 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 BGPpara 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 lacoincidencia 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 ynada 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 stampmatch as-path 1set 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 actualizacionesestá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 300network 170.10.0.0neighbor 3.3.3.3 remote-as 200neighbor 3.3.3.3 route-map stamp in

route-map stamp permit 10match as-path 1set weight 20

route-map stamp permit 20match as-path 2set 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 lasactualizaciones 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 unacorrespondencia 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 sistemasautónomos (AS) diferentes, AS100 y AS200. Cuando la información se propaga a AS600, los routers de AS600 tienen información deaccesibilidad 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 AS400con 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 porAS100 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 seanuncia en AS100. Una práctica común es repetir el propio número de AS de la forma siguiente:

RTC#router bgp 300network 170.10.0.0neighbor 2.2.2.2 remote-as 100neighbor 2.2.2.2 route-map SETPATH out

route-map SETPATHset 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). Estainformació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 dedistribución y las listas de filtrado definen habitualmente dichas políticas. No se definen las mismas para cada vecino, sino que se define unnombre 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 paraanular 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 unacorrespondencia 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 depares 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. Estalista 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 depares 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. Estafunción se encuentra también disponible en versiones posteriores del software Cisco IOS. La función introduce un nuevo algoritmo que calcula yoptimiza dinámicamente grupos de actualización de los vecinos que comparten las mismas políticas de salida. Estos vecinos pueden compartir losmismos mensajes de actualización. En versiones anteriores de Cisco IOS, el grupo de mensajes de actualización de BGP era la base de lasconfiguraciones del grupo de pares. Este método para agrupar actualizaciones limitaba las políticas de salida y las configuraciones de sesiónespecí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 delgrupo de pares. Esta separación mejora el tiempo de convergencia y la flexibilidad de la configuración del vecino. Consulte BGP DynamicUpdate Peer-Groups (Grupos de pares de actualización dinámica BGP) para obtener más información.


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 unanueva 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, porejemplo, 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 lamá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 devarias 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 parapropagar una superred de dicha ruta 160.0.0.0 en RTA:

RTB#router bgp 200neighbor 3.3.3.1 remote-as 300network 160.10.0.0

#RTCrouter bgp 300neighbor 3.3.3.3 remote-as 200neighbor 2.2.2.2 remote-as 100network 170.10.0.0aggregate-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 laagrupació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 adicional160.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 puedeefectuar 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. Estainyecció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 lasactualizaciones 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. Estaacció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 laruta. 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ífica160.20.0.0 y permitir la propagación de 160.10.0.0. Use la correspondencia de la ruta siguiente:

route-map CHECK permit 10match ip address 1

access-list 1 permit 160.20.0.0 0.0.255.255access-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 300neighbor 3.3.3.3 remote-as 200neighbor 2.2.2.2 remote-as 100neighbor 2.2.2.2 remote-as 100network 170.10.0.0aggregate-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 agrupacionesen IGP, aplique la correspondencia de la ruta siguiente al comando aggregate attribute-map:

route-map SETMETRICset 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 lared 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 singenerar una entrada para 160.10.0.0, aunque use el comando aggregate summary-only. RTB genera las dos redes porque RTB es quien origina160.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 200neighbor 3.3.3.1 remote-as 300redistribute 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 ladiferencia de que define el origen de la actualización en IGP.

RTB#router bgp 200network 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 300redistribute staticip 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 unavez, 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 recibela 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 yenviarla a RTD. RTD desconoce el origen de dicha ruta. Si agrega la sentencia aggregate as-set, está obligando a RTC a generar información detrayecto en la forma de un conjunto {}. Dicho conjunto incluye toda la información de trayecto, independientemente de cual fuera el primertrayecto.

RTB#router bgp 200network 160.10.0.0neighbor 3.3.3.1 remote-as 300

RTA#router bgp 100network 160.20.0.0neighbor 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 sehubiera originado desde AS300.

RTC#router bgp 300neighbor 3.3.3.3 remote-as 200neighbor 2.2.2.2 remote-as 100neighbor 4.4.4.4 remote-as 400aggregate 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 uncontrol 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 unAS en varios otros y asignar el grupo completo a una única confederación. Cada AS tiene su iBGP totalmente interconectado y conexiones aotros 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 elmundo 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 hayinterés por los interlocutores BGP que tienen conexiones eBGP con otros AS. Si desea crear una interconexión de iBGP completa dentro deAS500, 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 mundoexterior 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 deconfederació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 50bgp confederation identifier 500bgp confederation peers 60 70neighbor 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 60bgp confederation identifier 500bgp confederation peers 50 70neighbor 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, uninterlocutor BGP no anuncia una ruta cuya existencia conoció por otro interlocutor iBGP a un tercer interlocutor iBGP. Puede relajar un poco estarestricción y proporcionar control adicional, que permite a un router anunciar, o reflejar, las rutas cuyo conocimiento ha adquirido iBGP a otrosinterlocutores 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 puedeelegir 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 RTCes 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ónRTC 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 esun "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 perteneceral mismo agrupamiento (grupo de clientes) o a otros. En una configuración sencilla, puede dividir el AS en varios agrupamientos. Cada RR seconfigura con otros RR como pares no clientes en una topología completamente interconectada. Los clientes no deben crear pares coninterlocutores 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áses 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 clientesRTE 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 unaruta, efectúa el enrutamiento como se muestra en esta lista. Esta actividad depende, sin embargo, del tipo de par:

Rutas desde un par no cliente: refleja a todos los clientes dentro del agrupamiento.1.

Rutas desde un par cliente: refleja a todos los pares no clientes y también a los pares clientes.2.

Rutas desde un par eBGP: envía la actualización a todos los clientes y a los pares no clientes.3.

A continuación se presenta la configuración BGP relativa de los routers RTC, RTD y RTB:

RTC#

router bgp 100neighbor 2.2.2.2 remote-as 100neighbor 2.2.2.2 route-reflector-clientneighbor 1.1.1.1 remote-as 100neighbor 1.1.1.1 route-reflector-clientneighbor 7.7.7.7 remote-as 100neighbor 4.4.4.4 remote-as 100neighbor 8.8.8.8 remote-as 200

RTB#

router bgp 100neighbor 3.3.3.3 remote-as 100neighbor 12.12.12.12 remote-as 300

RTD#

router bgp 100neighbor 6.6.6.6 remote-as 100neighbor 6.6.6.6 route-reflector-clientneighbor 5.5.5.5 remote-as 100neighbor 5.5.5.5 route-reflector-clientneighbor 7.7.7.7 remote-as 100neighbor 3.3.3.3 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 dealgunos 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 incorporael 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 enrutamientovuelve 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 yevitar puntos de error, un agrupamiento puede tener más de un RR. Configure todos los RR del mismo agrupamiento con un ID de agrupamientode 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 deagrupamientos vacía, el RR crea una. Con este atributo, un RR puede identificar si la información de enrutamiento ha creado un bucle al mismoagrupamiento debido a una configuración incorrecta. Si el ID de agrupamiento local se encuentra en la lista de agrupamientos, el anuncio seomite.

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 100neighbor 4.4.4.4 remote-as 100neighbor 5.5.5.5 remote-as 100neighbor 5.5.5.5 route-reflector-clientneighbor 6.6.6.6 remote-as 100neighbor 6.6.6.6 route-reflector-clientneighbor 7.7.7.7 remote-as 100neighbor 3.3.3.3 remote-as 100neighbor 9.9.9.9 remote-as 300bgp cluster-id 10

RTD#

router bgp 100neighbor 10.10.10.10 remote-as 100neighbor 5.5.5.5 remote-as 100neighbor 5.5.5.5 route-reflector-clientneighbor 6.6.6.6 remote-as 100neighbor 6.6.6.6 route-reflector-clientneighbor 7.7.7.7 remote-as 100neighbor 3.3.3.3 remote-as 100neighbor 11.11.11.11 remote-as 400bgp cluster-id 10

RTF#

router bgp 100neighbor 10.10.10.10 remote-as 100neighbor 4.4.4.4 remote-as 100neighbor 13.13.13.13 remote-as 500

RTC#

router bgp 100neighbor 1.1.1.1 remote-as 100neighbor 1.1.1.1 route-reflector-clientneighbor 2.2.2.2 remote-as 100neighbor 2.2.2.2 route-reflector-clientneighbor 4.4.4.4 remote-as 100neighbor 7.7.7.7 remote-as 100neighbor 10.10.10.10 remote-as 100neighbor 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 directosentre ellos y los clientes intercambian actualizaciones a través del RR. Si configura grupos de pares, un posible repliegue al origen de una ruta enel 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 acliente 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 aestos routers interlocutores BGP convencionales. El esquema de RR permite la coexistencia de dichos interlocutores. Estos routers pueden sermiembros 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 almodelo RR. Puede empezar a crear agrupamiento si configura un único router como RR y hace que otros RR y otros clientes RR normales seanpares 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 puedeconfigurarlos como RR. Puede realizar una interconexión normal de iBGP entre estos routers y RTD. Más tarde, cuando esté listo para efectuaruna 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 100neighbor 6.6.6.6 remote-as 100neighbor 6.6.6.6 route-reflector-clientneighbor 5.5.5.5 remote-as 100neighbor 5.5.5.5 route-reflector-clientneighbor 3.3.3.3 remote-as 100neighbor 2.2.2.2 remote-as 100neighbor 1.1.1.1 remote-as 100neighbor 13.13.13.13 remote-as 300

RTC#

router bgp 100neighbor 4.4.4.4 remote-as 100neighbor 2.2.2.2 remote-as 100neighbor 1.1.1.1 remote-as 100neighbor 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 yRTB 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-idy 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 noafecta 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, laclá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 producenciertas rutas inestables. La amortiguación de rutas reduce también la oscilación en la red. Puede definir criterios para identificar las rutas que secomportan de forma incorrecta. Una ruta que es inestable recibe una penalización de 1000 por cada caso de inestabilidad. Cuando laspenalizaciones acumuladas llegan a un "límite de supresión" predefinido, se procede a la supresión del anuncio de ruta. La penalización se reduceexponencialmente 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". Eneste 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 futuropró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 4veces el valor de tiempo de mitad de vida.

RTB#hostname RTB

interface Serial0ip address 203.250.15.2 255.255.255.252


router bgp 100bgp dampeningnetwork 203.250.15.0neighbor 192.208.10.5 remote-as 300

RTD#hostname RTD

interface Loopback0ip address 192.208.10.174 255.255.255.192

interface Serial0/0ip address 192.208.10.5 255.255.255.252

router bgp 300network 192.208.10.0neighbor 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 esestable, la tabla BGP de RTB aparece como se indica a continuación:

RTB# show ip bgpBGP table version is 24, local router ID is 203.250.15.2 Status codes: ssuppressed, d damped, h history, * valid, > best, i - internal Origincodes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 192.208.10.0 192.208.10.5 0 0 300 i*> 203.250.15.0 0.0.0.0 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 acontinuación:

RTB# show ip bgpBGP table version is 24, local router ID is 203.250.15.2 Status codes: ssuppressed, d damped, h history, * valid, > best, i - internal Origincodes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Pathh 192.208.10.0 192.208.10.5 0 0 300 i*> 203.250.15.0 0.0.0.0 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íahay información sobre inestabilidad.

RTB# show ip bgp 192.208.10.0BGP routing table entry for 192.208.10.0 255.255.255.0, version 25Paths: (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, externalDampinfo: 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 bgpBGP 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 Next Hop Metric LocPrf Weight Path*d 192.208.10.0 192.208.10.5 0 0 300 i*> 203.250.15.0 0.0.0.0 0 32768 i

RTB# show ip bgp 192.208.10.0BGP routing table entry for 192.208.10.0 255.255.255.0, version 32Paths: (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, externalDampinfo: 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 dereutilizació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ímitede reutilización. En este caso, la depuración tiene lugar cuando la penalización es 375 (750/2=375). Los comandos siguientes muestran y borranla 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 secorresponden 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 unvecino.

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 deselección del mejor trayecto BGP).


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 deCisco.

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 unsistema 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 Ethernet0ip address 203.250.14.1 255.255.255.0


router ospf 10network 203.250.0.0 0.0.255.255 area 0

router bgp 100network 203.250.13.0network 203.250.14.0neighbor 128.213.63.2 remote-as 200neighbor 203.250.15.2 remote-as 100neighbor 203.250.15.2 update-source Loopback0

RTF#hostname RTF

ip subnet-zero




RTB#hostname RTB

ip subnet-zero




router bgp 100network 203.250.15.0neighbor 192.208.10.5 remote-as 300neighbor 203.250.13.41 remote-as 100

RTC#hostname RTC

ip subnet-zero


interface Serial2/0ip address 128.213.63.5 255.255.255.252!interface Serial2/1ip address 128.213.63.2 255.255.255.252


RTD#hostname RTD

ip subnet-zero




RTE#hostname RTE

ip subnet-zero



interface Serial1ip address 128.213.63.6 255.255.255.252clockrate 1000000


RTG#hostname RTG

ip subnet-zero





Use siempre el comando network o redistribuya entradas estáticas en BGP para anunciar redes. Este método es mejor que redistribuir IGP enBGP. 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 seindica a continuación:

RTB# show ip bgp BGPtable version is 4, local router ID is 203.250.15.2 Statuscodes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin 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 500300 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 siguientede 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 SelectionAlgorithm (Algoritmo de selección del mejor trayecto BGP). BGP selecciona el mejor trayecto para llegar a un destino, lo instala en latabla 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 saltosiguiente eBGP que se ejecuta en iBGP.

Consulte la tabla de enrutamiento de IP:

RTB# show ip routeCodes: 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, * - candidatedefault

Gateway of last resort is not set

203.250.13.0 255.255.255.255 is subnetted, 1 subnetsO 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 subnetsC 203.250.15.0 is directly connected, Serial0O 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 siguientemediante este IGP, que es OSPF. RTB no ha obtenido conocimiento de 128.213.63.0 mediante OSPF. Puede ejecutar OSPF en la interfaz s0 deRTA 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 apareceaquí:

RTA#hostname RTA

ip subnet-zero




router ospf 10passive-interface Serial0network 203.250.0.0 0.0.255.255 area 0network 128.213.0.0 0.0.255.255 area 0

router bgp 100network 203.250.0.0 mask 255.255.0.0neighbor 128.213.63.2 remote-as 200neighbor 203.250.15.2 remote-as 100neighbor 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 bgpBGP table version is 10, local router ID is 203.250.15.2Status 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 500300 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

Nota: todas las entradas tienen >, lo que significa que BGP puede tener acceso al salto siguiente.

Consulte la tabla de enrutamiento:

RTB# show ip routeCodes: 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


203.250.13.0 255.255.255.255 is subnetted, 1 subnetsO 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 subnetsC 203.250.15.0 is directly connected, Serial0O 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 subnetsO 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 accesoa 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 lasenví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:



B 200.200.10.0 [200/0] via 128.213.63.2, 00:01:07B 195.211.10.0 [200/0] via 128.213.63.2, 00:01:07B 192.208.10.0 [200/0] via 128.213.63.2, 00:01:07 203.250.13.0 is variably subnetted, 2 subnets, 2 masksO 203.250.13.41 255.255.255.255 [110/75] via 203.250.15.1, 00:12:37, Serial0B 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 subnetsC 203.250.15.0 is directly connected, Serial0O 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 masksB 128.213.0.0 255.255.0.0 [200/0] via 128.213.63.2, 00:01:08O 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 obteneracceso a ellas:

RTF# show ip routeCodes: 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


203.250.13.0 255.255.255.255 is subnetted, 1 subnetsO 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 subnetsC 203.250.15.0 is directly connected, Serial1C 203.250.14.0 is directly connected, Ethernet0 128.213.0.0 255.255.255.252 is subnetted, 1 subnetsO 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 adelantepara otros temas. Redistribuya BGP en OSPF en RTA, con una métrica de 2000:

RTA#hostname RTA

ip subnet-zero




router ospf 10redistribute bgp 100 metric 2000 subnetspassive-interface Serial0network 203.250.0.0 0.0.255.255 area 0network 128.213.0.0 0.0.255.255 area 0

router bgp 100network 203.250.0.0 mask 255.255.0.0neighbor 128.213.63.2 remote-as 200neighbor 203.250.15.2 remote-as 100neighbor 203.250.15.2 update-source Loopback0

La tabla de enrutamiento es como se indica a continuación:



O E2 200.200.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0O E2 195.211.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0O 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 masksO 203.250.13.41 255.255.255.255 [110/75] via 203.250.15.1, 00:00:15, Serial0O 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 subnetsC 203.250.15.8 is directly connected, Loopback1C 203.250.15.0 is directly connected, Serial0O 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 masksO E2 128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1,00:00:15,Serial0O 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 iBGPes 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 OSPFdebido 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 esnecesaria 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 pasopermite a RTA tener conocimiento del salto siguiente 192.208.10.5 a través de IGP. Si lo omite, pueden producirse bucles de enrutamientoporque 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 nuevasconfiguraciones de RTA y RTB:

RTA#hostname RTA

ip subnet-zero


interface Ethernet0

ip address 203.250.14.1 255.255.255.0



router bgp 100no synchronizationnetwork 203.250.13.0network 203.250.14.0neighbor 128.213.63.2 remote-as 200neighbor 203.250.15.2 remote-as 100neighbor 203.250.15.2 update-source Loopback0

RTB#hostname RTB

ip subnet-zero




router bgp 100no synchronizationnetwork 203.250.15.0neighbor 192.208.10.5 remote-as 300neighbor 203.250.13.41 remote-as 100

La tabla BGP es como se indica a continuación:

RTA# show ip bgpBGP table version is 117, local router ID is 203.250.13.41Status 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*> 128.213.0.0 128.213.63.2 0 0 200 i*>i192.208.10.0 192.208.10.5 0 100 0 300 i*>i195.211.10.0 192.208.10.5 100 0 300 500 i* 128.213.63.2 0 200 400 500 i*> 200.200.10.0 128.213.63.2 0 200 400 i*> 203.250.13.0 0.0.0.0 0 32768 i*> 203.250.14.0 0.0.0.0 0 32768 i*>i203.250.15.0 203.250.15.2 0 100 0 i

RTB# show ip bgpBGP table version is 12, local router ID is 203.250.15.10Status 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* 192.208.10.5 0 300 500 400200 i*> 192.208.10.0 192.208.10.5 0 0 300 i*> 195.211.10.0 192.208.10.5 0 300 500 i*>i200.200.10.0 128.213.63.2 100 0 200 400 i* 192.208.10.5 0 300 500 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

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 unISP de respaldo. Puede tener conocimiento de rutas parciales por uno de los ISP y asignar rutas predeterminadas a ambos. En este ejemplo, reciberutas 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 dedirecciones IP, la misma red principal, cuando se comunica con los dos ISP. Debido a la agrupación, el mundo exterior verá el AS como unaentidad 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 porun único punto, aunque disponga de múltiples puntos en Internet. En este ejemplo, tiene dos redes principales importantes cuando se comunicacon 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 deservicios 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 setransfiere 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 prependpara agregar números de trayecto a las actualizaciones y hacer que la longitud parezca más larga. Sin embargo, con atributos como preferencialocal, 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




router ospf 10redistribute bgp 100 metric 2000 subnetspassive-interface Serial0network 203.250.0.0 0.0.255.255 area 0network 128.213.0.0 0.0.255.255 area 0default-information originate metric 2000

router bgp 100no synchronizationnetwork 203.250.13.0network 203.250.14.0neighbor 128.213.63.2 remote-as 200neighbor 128.213.63.2 route-map setlocalpref inneighbor 203.250.15.2 remote-as 100neighbor 203.250.15.2 update-source Loopback0

ip classlessip default-network 200.200.0.0

route-map setlocalpref permit 10set 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 comocandidata 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 dominioOSPF. 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ónpredeterminada en el dominio de IGP tiene lugar tras la redistribución de BGP en IGRP y EIGRP. Con IGRP y EIGRP, también puederedistribuir una ruta estática de 0.0.0.0 en el ámbito de IGP.

RTF#hostname RTF

ip subnet-zero




ip classless

RTB#hostname RTB

ip subnet-zero


interface Serial0ip address 203.250.15.2 255.255.255.252!interface Serial1ip address 192.208.10.6 255.255.255.252

router ospf 10redistribute bgp 100 metric 1000 subnetspassive-interface Serial1network 203.250.0.0 0.0.255.255 area 0network 192.208.10.6 0.0.0.0 area 0default-information originate metric 1000!router bgp 100no synchronizationnetwork 203.250.15.0neighbor 192.208.10.5 remote-as 300neighbor 192.208.10.5 route-map localonly inneighbor 203.250.13.41 remote-as 100!ip classlessip default-network 192.208.10.0ip as-path access-list 1 permit ^300$

route-map localonly permit 10match as-path 1set 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 preferencialocal de las actualizaciones de iBGP que proceden de RTA. De esta forma, AS100 selecciona RTB para las rutas locales de AS300. Cualquierotra 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, queprocede 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 lasrutas 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.10Status codes: s suppressed, d damped, h history, * valid, > best, i -internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 192.208.10.0 192.208.10.5 0 300 0 300

RTC#hostname RTC

ip subnet-zero



router bgp 200network 128.213.0.0neighbor 128.213.63.1 remote-as 100neighbor 128.213.63.1 distribute-list 1 outneighbor 128.213.63.6 remote-as 400

ip classlessaccess-list 1 deny 195.211.0.0 0.0.255.255access-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 Loopback0ip address 192.208.10.174 255.255.255.192!interface Serial0/0ip address 192.208.10.5 255.255.255.252!interface Serial0/1ip address 192.208.10.2 255.255.255.252


RTG#hostname RTG

ip subnet-zero




router bgp 500network 195.211.10.0aggregate-address 195.211.0.0 255.255.0.0 summary-onlyneighbor 192.208.10.2 remote-as 300neighbor 192.208.10.2 send-communityneighbor 192.208.10.2 route-map setcommunity outneighbor 195.211.10.2 remote-as 400!ip classlessaccess-list 1 permit 195.211.0.0 0.0.255.255access-list 2 permit anyroute-map setcommunity permit 20match ip address 2!route-map setcommunity permit 10match ip address 1set 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 de195.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




router bgp 400network 200.200.10.0aggregate-address 200.200.0.0 255.255.0.0 summary-onlyneighbor 128.213.63.5 remote-as 200neighbor 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 bgpBGP table version is 21, local router ID is 203.250.13.41Status codes: s suppressed, d damped, h history, * valid, > best, i -internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 128.213.0.0 128.213.63.2 0 200 0 200 i*>i192.208.10.0 192.208.10.5 0 300 0 300 i*> 200.200.0.0/16 128.213.63.2 200 0 200 400 i*> 203.250.13.0 0.0.0.0 0 32768 i*> 203.250.14.0 0.0.0.0 0 32768 i*>i203.250.15.0 203.250.15.2 0 100 0 i

RTA# show ip routeCodes: 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 masksO E2 192.208.10.0 255.255.255.0 [110/1000] via 203.250.14.2, 00:41:25, Ethernet0O 192.208.10.4 255.255.255.252 [110/138] via 203.250.14.2, 00:41:25, Ethernet0C 203.250.13.0 is directly connected, Loopback0 203.250.15.0 is variably subnetted, 3 subnets, 3 masksO 203.250.15.10 255.255.255.255 [110/75] via 203.250.14.2, 00:41:25, Ethernet0O 203.250.15.0 255.255.255.252 [110/74] via 203.250.14.2, 00:41:25, Ethernet0B 203.250.15.0 255.255.255.0 [200/0] via 203.250.15.2, 00:41:25C 203.250.14.0 is directly connected, Ethernet0 128.213.0.0 is variably subnetted, 2 subnets, 2 masksB 128.213.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:41:26C 128.213.63.0 255.255.255.252 is directly connected, Serial0O*E2 0.0.0.0/0 [110/1000] via 203.250.14.2, Ethernet0/0B* 200.200.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:02:38

RTF# show ip routeCodes: 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


192.208.10.0 is variably subnetted, 2 subnets, 2 masksO E2 192.208.10.0 255.255.255.0 [110/1000] via 203.250.15.2, 00:48:50, Serial1O 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 masksO 203.250.13.41 255.255.255.255 [110/11] via 203.250.14.1, 01:12:09, Ethernet0O 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 masksO 203.250.15.10 255.255.255.255 [110/65] via 203.250.15.2, 01:12:09, Serial1C 203.250.15.0 255.255.255.252 is directly connected, Serial1C 203.250.14.0 is directly connected, Ethernet0 128.213.0.0 is variably subnetted, 2 subnets, 2 masksO E2 128.213.0.0 255.255.0.0 [110/2000] via 203.250.14.1, 00:45:01, Ethernet0O 128.213.63.0 255.255.255.252 [110/74] via 203.250.14.1, 01:12:11, Ethernet0O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.14.1, 00:03:47,Ethernet0O*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. Laforma 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 bgpBGP table version is 14, local router ID is 203.250.15.10Status codes: s suppressed, d damped, h history, * valid, > best, i -internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*>i128.213.0.0 128.213.63.2 0 200 0 200 i*> 192.208.10.0 192.208.10.5 0 300 0 300 i*>i200.200.0.0/16 128.213.63.2 200 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



* 192.208.10.0 is variably subnetted, 2 subnets, 2 masksB* 192.208.10.0 255.255.255.0 [20/0] via 192.208.10.5, 00:50:46C 192.208.10.4 255.255.255.252 is directly connected, Serial1 203.250.13.0 is variably subnetted, 2 subnets, 2 masksO 203.250.13.41 255.255.255.255 [110/75] via 203.250.15.1, 01:20:33, Serial0O 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 subnetsC 203.250.15.8 is directly connected, Loopback1C 203.250.15.0 is directly connected, Serial0O 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 masksO E2 128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:46:55, Serial0O 128.213.63.0 255.255.255.252 [110/138] via 203.250.15.1, 01:20:34, Serial0O*E2 0.0.0.0/0 [110/2000] via 203.250.15.1, 00:08:33, Serial0O 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

Education

Funcionamiento de BGP en equipos Cisco