IP : Routing IP

Estudios de casos de BGP

23 Junio 2008 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (30 Octubre 2008) | Comentarios

Contenidos

Introducción
Requisitos previos
     Requisitos
     Componentes utilizados
     Convenciones
Estudios de casos de BGP 1
     ¿Cómo funciona BGP?
     eBGP e iBGP
     Habilitación del enrutamiento BGP
     Formación de vecinos BGP
     BGP y las interfaces de bucle de retorno
     eBGP de varios saltos
     eBGP de varios saltos (balance de carga)
     Correspondencias de la ruta
     Comandos de configuración match y set
     El comando network
     Redistribución
     Rutas estáticas y redistribución
     iBGP
     El algoritmo de decisión BGP
Estudios de casos de BGP 2
     Atributo AS_PATH
     Atributo de origen
     Atributo de salto siguiente de BGP
     Entrada posterior de BGP
     Sincronización
     Atributo de peso
     Atributo de preferencia local
     Atributo de métrica
     Atributo de comunidad
Estudios de casos de BGP 3
     Filtrado de BGP
     Expresión normal de AS
     Vecinos y correspondencias de la ruta BGP
Estudios de casos de BGP 4
     CIDR y direcciones de agrupación
     Confederación de BGP
     Reflectores de ruta
     Amortiguación de la inestabilidad de las rutas
     Selección de un trayecto por parte de BGP
Estudios de casos de BGP 5
     Ejemplo de diseño práctico
Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

Este documento contiene cinco conjuntos de estudios de casos relacionados con el Protocolo de gateway de frontera (BGP).

Requisitos previos

Requisitos

No hay requisitos específicos para este documento.

Componentes utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y hardware.

Convenciones

Consulte Cisco Technical Tips Conventions (Convenciones sobre consejos técnicos de Cisco) para obtener más información sobre las convenciones del documento.

Estudios de casos de BGP 1

El BGP, que se define en RFC 1771 leavingcisco.com, permite crear enrutamientos interdominio sin bucles entre sistemas autónomos (AS). Un sistema autónomo es un conjunto de routers bajo una sola administración técnica. Los routers de un AS pueden usar varios protocolos de gateway interior (IGP) para intercambiar información de enrutamiento dentro del sistema autónomo. Los routers pueden usar un protocolo de gateway exterior (EGP) para enrutar paquetes fuera del AS.

¿Cómo funciona BGP?

BGP usa TCP como el protocolo de transporte en el puerto 179. Dos routers BGP forman una conexión TCP entre sí. Estos routers son routers pares, que intercambian mensajes para abrir y confirmar los parámetros de conexión.

Los routers BGP intercambian información de accesibilidad de la red. Esta información es, básicamente, una indicación de los trayectos completos que debe tomar un router para alcanzar la red de destino. Los trayectos son números de AS BGP. Esta información ayuda a crear un gráfico de los AS sin bucles. El gráfico muestra también dónde deben aplicarse las políticas de enrutamiento para imponer algunas restricciones en el comportamiento del enrutamiento.

Dos routers cualquiera que formen una conexión TCP para intercambiar información de enrutamiento BGP son "pares" o "vecinos". Los pares BGP intercambian inicialmente las tablas completas de enrutamiento BGP. Tras este intercambio, envían actualizaciones incrementales a medida que cambia la tabla de enrutamiento. BGP conserva un número de versión de la tabla BGP. El número de versión es el mismo para todos los pares BGP y se modifica cada vez que BGP actualiza la tabla con los cambios en la información de enrutamiento. El envío de paquetes de señal de mantenimiento garantiza que la conexión entre los pares BGP se mantenga activa. Los paquetes de notificación se generan en respuesta a errores o condiciones especiales.

eBGP e iBGP

Si un sistema autónomo (AS) tiene varios interlocutores BGP, puede servir como un servicio de tránsito para otros AS. Como muestra el diagrama de esta sección, AS200 es un AS de tránsito para AS100 y AS300.

Para enviar la información a AS externos, es necesario asegurarse de que es posible tener acceso a las redes. Para garantizar esta accesibilidad, se ejecutan los procesos siguientes:

  • Establecimiento de pares iBGP (BGP interno) entre routers dentro de un AS

  • Redistribución de información de BGP a los IGP que se ejecutan en el AS

Cuando BGP se ejecuta entre routers que pertenecen a dos AS diferentes, recibe el nombre de BGP externo (eBGP). Cuando BGP se ejecuta entre routers del mismo AS, recibe el nombre de iBGP.

bgp-toc1.gif

Habilitación del enrutamiento BGP

Siga los pasos siguientes para habilitar y configurar BGP.

Supongamos que desea tener dos routers, RTA y RTB, que se comuniquen a través de BGP. En el primer ejemplo, RTA y RTB se encuentran en AS diferentes. En el segundo, los dos routers pertenecen al mismo AS.

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

    Ejecute el comando siguiente para habilitar BGP en un router:

                      router bgp autonomous-system
                      
    RTA#
    router bgp 100
    
    RTB#
    router bgp 200

    Estas sentencias indican que RTA ejecuta BGP y que pertenece a AS100. RTB ejecuta BGP y pertenece a AS200.

  2. Defina los vecinos BGP.

    La formación de vecinos BGP identifica los routers que intentarán conectarse mediante BGP. En la sección Formación de vecinos BGP se explica este proceso.

Formación de vecinos BGP

Dos routers BGP se convierten en vecinos cuando establecen una conexión TCP entre sí. La conexión TCP es esencial para que los dos routers pares inicien el intercambio de actualizaciones de enrutamiento.

Cuando la conexión TCP está activa, los routers envían mensajes abiertos para intercambiar valores. Estos valores son el número de AS, la versión de BGP que ejecutan, el ID del router BGP y el tiempo de espera de la señal de mantenimiento. Tras confirmarlos y aceptarlos, se establece la conexión con el vecino. Cualquier estado diferente a Established indica que los dos routers no se han convertido en vecinos y que no pueden intercambiar actualizaciones BGP.

Ejecute este comando neighbor para establecer una conexión TCP:

            neighbor ip-address remote-as number
            
         

En el comando, number es el número de AS del router al que desea conectar con BGP. ip-address es la dirección de salto siguiente con conexión directa para eBGP. En iBGP, ip-address es una dirección IP en otro router.

Las dos direcciones IP que usa en el comando neighbor de los routers pares deben poder conectarse entre sí. Una forma de verificar la accesibilidad es efectuar un ping ampliado entre las dos direcciones IP. El ping ampliado obliga al router que hace ping a usar como origen la dirección IP que especifica el comando neighbor. Debe usar esta dirección en lugar de la dirección IP de la interfaz desde la que se transfiere el paquete.

Si se produce algún cambio en la configuración de BGP, debe reiniciar la conexión con el vecino para permitir que los nuevos parámetros tengan efecto.

  • clear ip bgp address

    Nota:  address es la dirección del vecino.

  • clear ip bgp *

    Este comando borra todas las conexiones vecinas.

De forma predeterminada, las sesiones BGP empiezan usando la versión 4 de BGP y, si es necesario, negocian de manera descendente hacia versiones anteriores. Puede impedir las negociaciones e imponer la versión de BGP que usan los routers para comunicarse con un vecino. Ejecute el comando siguiente en el modo de configuración del router:

            neighbor {ip address | peer-group-name} version value
            

         

A continuación se proporciona un ejemplo de la configuración del comando neighbor:

bgp-toc2.gif

RTA#
router bgp 100
neighbor 129.213.1.1 remote-as 200

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

RTC#
router bgp 200
neighbor 175.220.212.1 remote-as 200

En este ejemplo, RTA y RTB ejecutan eBGP. RTB y RTC ejecutan iBGP. El número de AS remoto señala un AS externo o interno, lo que indica eBGP o iBGP. Además, los pares eBGP tienen conexión directa, pero los pares iBGP no. Los routers iBGP no la necesitan. Sin embargo, debe haber algún IGP en ejecución que permita que dos vecinos puedan conectarse entre sí.

En esta sección se ofrece un ejemplo de la información que muestra el comando show ip bgp neighbors.

Nota: ponga especial atención al estado de BGP. Cualquier estado que no sea Established indica que los pares no funcionan.

Nota: observe también los elementos siguientes:

  • La entrada BGP version, que es 4

  • La entrada remote router ID

    Este número es la dirección IP más elevada en el router, o la interfaz de bucle de retorno más elevada, si la hay.

  • La entrada table version

    La entrada table version informa del estado de la tabla. Cada vez que se especifica información nueva, la tabla incrementa la versión. Si una versión continúa incrementándose, significa que hay alguna ruta inestable que provoca la actualización continuada de las rutas.

# show ip bgp neighbors
     BGP neighbor is 129.213.1.1, remote AS 200, external link
     BGP version 4, remote router ID 175.220.12.1
     BGP state = Established, table version = 3, up for 0:10:59
     Last read 0:00:29, hold time is 180, keepalive interval is 60 seconds
     Minimum time between advertisement runs is 30 seconds
     Received 2828 messages, 0 notifications, 0 in queue
     Sent 2826 messages, 0 notifications, 0 in queue
     Connections established 11; dropped 10 

BGP y las interfaces de bucle de retorno

Es muy habitual en iBGP usar una interfaz de bucle de retorno para definir vecinos, pero no lo es en eBGP. Generalmente, una interfaz de bucle de retorno se usa para verificar si la dirección IP del vecino está activa y no depende de que el hardware funcione correctamente. En el caso de eBGP, los routers pares tienen habitualmente conexión directa y el bucle de retorno no se aplica.

Si usa la dirección IP de una interfaz de bucle de retorno en el comando neighbor necesita configuración adicional en el router vecino. El router vecino debe informar a BGP del uso de una interfaz de bucle de retorno, en lugar de una interfaz física, para iniciar la conexión TCP del BGP vecino. Para indicar una interfaz de bucle de retorno, ejecute el comando siguiente:

            neighbor ip-address update-source interface
            
         

Este ejemplo muestra el uso de este comando:

bgp-toc3.gif

RTA#
     router bgp 100
     neighbor 190.225.11.1 remote-as 100
     neighbor 190.225.11.1 update-source loopback 1
RTB#
     router bgp 100
     neighbor 150.212.1.1 remote-as 100 

En este ejemplo, RTA y RTB ejecutan iBGP dentro de AS100. En el comando neighbor, RTB usa la interfaz de bucle de retorno de RTA, 150.212.1.1. En este caso, RTA debe obligar a BGP a que use la dirección IP del bucle de retorno como el origen de la conexión TCP del vecino. Para forzar esta acción, RTA agrega update-source interface-type interface-number de modo que el comando es neighbor 190.225.11.1 update-source loopback 1. Esta sentencia obliga a BGP a usar la dirección IP de la interfaz de bucle de retorno cuando BGP se comunica con 190.225.11.1.

Nota: RTA ha usado la dirección IP de la interfaz física de RTB, 190.225.11.1, como un vecino. El uso de esta dirección IP es el motivo por el que RTB no requiere una configuración especial. Consulte Sample Configuration for iBGP and eBGP With or Without a Loopback Address (Ejemplo de configuración de iBGP y eBGP con o sin dirección de bucle de retorno) para obtener una configuración completa de ejemplo del escenario de red.

eBGP de varios saltos

En algunos casos, el router de Cisco puede ejecutar eBGP con un router de otro fabricante que no permita la conexión directa de los dos pares externos. Para conseguir la conexión, puede usar el eBGP de varios saltos. El eBGP de varios saltos permite una conexión vecina entre dos pares externos que no tienen conexión directa. El eBGP de varios saltos sólo se aplica a eBGP y no a iBGP. El ejemplo siguiente muestra el eBGP de varios saltos:

bgp-toc4.gif

RTA#
router bgp 100
neighbor 180.225.11.1 remote-as 300
neighbor 180.225.11.1 ebgp-multihop
RTB#
router bgp 300
neighbor 129.213.1.2 remote-as 100

RTA indica un vecino externo que no tiene conexión directa. RTA debe indicar su uso del comando ebgp-multihop. Por otra parte, RTB indica un vecino que tiene conexión directa, que es 129.213.1.2. Debido a esta conexión directa, RTB no necesita el comando ebgp-multihop. También debería configurar un IGP o enrutamiento estático para permitir que los vecinos sin conexión puedan conectarse entre sí.

El ejemplo de la sección eBGP de varios saltos (balance de carga) muestra cómo se puede conseguir un balance de carga con BGP en caso de tener eBGP en líneas paralelas.

eBGP de varios saltos (balance de carga)

bgp-toc5.gif

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

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

ip route 150.10.0.0 255.255.0.0 1.1.1.1
ip route 150.10.0.0 255.255.0.0 2.2.2.1

Este ejemplo muestra el uso de las interfaces de bucle de retorno update-source y ebgp-multihop. Se trata de una solución provisional para conseguir el balance de carga entre dos interlocutores eBGP en líneas de serie paralelas. En situaciones normales, BGP selecciona una de las líneas en las que envía paquetes, y el balance de carga no tiene lugar. Con la introducción de las interfaces de bucle de retorno, el siguiente salto para eBGP es la interfaz de bucle de retorno. Se usan rutas estáticas o un IGP para introducir dos trayectos de igual costo para conseguir comunicarse con el destino. RTA tiene dos opciones para alcanzar el salto siguiente 160.10.1.1: un trayecto mediante 1.1.1.2 y otro mediante 2.2.2.2. RTB tiene las mismas opciones.

Correspondencias de la ruta

Las correspondencias de la ruta se usan con mucha frecuencia en BGP. En este contexto, es un método para controlar y modificar la información de enrutamiento. El control y la modificación de la información de enrutamiento se efectúan mediante la definición de condiciones para la redistribución de rutas de un protocolo de enrutamiento a otro. Aunque también se puede efectuar en la inyección de entrada y de salida de BGP. El formato de una correspondencia de la ruta es el siguiente:

            route-map map-tag [[permit | deny] | [sequence-number]] 

         

La etiqueta de correspondencia es un nombre que se proporciona a la correspondencia de la ruta. Puede definir varias instancias de la misma correspondencia o la misma etiqueta de nombre. El número de secuencia indica la posición que debe tener una nueva correspondencia de la ruta en la lista de correspondencias que ya ha configurado con el mismo nombre.

En este ejemplo, se han definido dos instancias de correspondencia de la ruta con el nombre MYMAP. La primera tiene un número de secuencia de 10 y la segunda, de 20.

  • route-map MYMAP permit 10 (el primer conjunto de condiciones se indica aquí).

  • route-map MYMAP permit 20 (el segundo conjunto de condiciones se indica aquí).

Cuando aplique la correspondencia de la ruta MYMAP a las rutas de entrada o salida, se aplica el primer conjunto de condiciones mediante la instancia 10. Si no se cumple con el primer conjunto de condiciones, debe usar una instancia superior de la correspondencia de la ruta.

Comandos de configuración match y set

Cada correspondencia de la ruta consiste en una lista de comandos de configuración match y set. El primero especifica un criterio match y el segundo una acción set si se cumplen los criterios que impone el comando match.

Por ejemplo, puede definir una correspondencia de la ruta que verifique las actualizaciones de salida. Si hay una concordancia para la dirección IP 1.1.1.1, la métrica para dicha actualización se establece en 5. Estos comandos ilustran el ejemplo:

            match ip address 1.1.1.1
            

            set metric 5
            
         

Si se cumple con los criterios de concordancia y se tiene un valor permit, hay una redistribución o control de las rutas, como especifica la acción set. Se encontrará fuera de la lista.

Si se cumple con los criterios de concordancia y se tiene un valor deny, no hay una redistribución o control de la ruta. Se encontrará fuera de la lista.

Si no se cumple con los criterios de concordancia y se tiene un valor permit o deny, se verifica la siguiente instancia de la correspondencia de la ruta. Se verifica, por ejemplo, la instancia 20. Esta verificación de la siguiente instancia continúa hasta que se encuentra fuera o finaliza todas las instancias de la correspondencia de la ruta. Si finaliza la lista sin encontrar ninguna concordancia, la ruta no se acepta ni se reenvía.

En versiones anteriores a la versión 11.2 del software Cisco IOS®, cuando se usan correspondencias de la ruta para filtrar actualizaciones BGP en lugar de redistribuir entre protocolos, no se puede filtrar en la salida cuando se usa un comando match en la dirección IP. Un filtro de salida se puede aceptar. La versión 11.2 y posteriores del software Cisco IOS no tienen esta restricción.

Los comandos relacionados de match son los siguientes:

  • match as-path

  • match community

  • match clns

  • match interface

  • match ip address

  • match ip next-hop

  • match ip route-source

  • match metric

  • match route-type

  • match tag

Los comandos relacionados de set son los siguientes:

  • set as-path

  • set clns

  • set automatic-tag

  • set community

  • set interface

  • set default interface

  • set ip default next-hop

  • set level

  • set local-preference

  • set metric

  • set metric-type

  • set next-hop

  • set origin

  • set tag

  • set weight

Examine algunos ejemplos de correspondencia de la ruta:

bgp-toc6.gif

Ejemplo 1

Supongamos que RTA y RTB ejecutan el Protocolo de información de enrutamiento (RIP), y que RTA y RTC ejecutan BGP. RTA recibe las actualizaciones mediante BGP y las redistribuye a RIP. Imaginemos que RTA desea redistribuir a las rutas RTB de 170.10.0.0 con una métrica de 2 y el resto de rutas con una métrica de 5. En este caso, puede usar la configuración siguiente:

RTA#
router rip
network 3.0.0.0
network 2.0.0.0
network 150.10.0.0
passive-interface Serial0
redistribute bgp 100 route-map SETMETRIC

router bgp 100
neighbor 2.2.2.3 remote-as 300
network 150.10.0.0

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

route-map SETMETRIC permit 20
set metric 5

access-list 1 permit 170.10.0.0 0.0.255.255

En este ejemplo, si una ruta concuerda con la dirección IP 170.10.0.0, la ruta tiene una métrica de 2. Por lo tanto, se encuentra fuera de la lista de correspondencias de la ruta. Si no hay ninguna concordancia, sigue por la lista hacia abajo, lo que significa que el resto se establece en la métrica 5.

Nota: hágase siempre la pregunta "¿Qué ocurre a las rutas que no concuerdan con ninguna sentencia de coincidencia?". De forma predeterminada, estas rutas se descartan.

Ejemplo 2

Supongamos que en el ejemplo 1 no desea que AS100 acepte actualizaciones de 170.10.0.0. No puede aplicar correspondencias de la ruta en la salida cuando hay una concordancia con una dirección IP como base. Debe usar, por lo tanto, una correspondencia de la ruta de salida en RTC:

RTC#

router bgp 300
network 170.10.0.0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map STOPUPDATES out

route-map STOPUPDATES permit 10
match ip address 1

access-list 1 deny 170.10.0.0 0.0.255.255
access-list 1 permit 0.0.0.0 255.255.255.255

Ahora que ya sabe cómo iniciar BGP y cómo definir un vecino, observe cómo se inicia el intercambio de información de red.

Hay varias formas de enviar la información de red con BGP. Estas secciones analizan los métodos uno por uno:

El comando network

El formato del comando network es:

            network network-number [mask network-mask]

         

El comando network controla las redes que se originan desde este recuadro. Este concepto difiere de la configuración más habitual que se efectúa con el Protocolo de enrutamiento de gateway interior (IGRP) y RIP. Con este comando, el usuario no intenta ejecutar BGP en una determinada interfaz. En su lugar, intenta indicar a BGP las redes BGP que se deben originar desde este recuadro. El comando usa una porción de máscara porque la versión 4 de BGP (BGP4) puede gestionar subredes y superredes. Se acepta un máximo de 200 entradas del comando network.

network funciona si el router tiene conocimiento de la red que se intenta anunciar, ya sea una red conectada, estática o cuyo conocimiento se haya adquirido de forma dinámica.

Un ejemplo del comando network es:

RTA#
router bgp 1
network 192.213.0.0 mask 255.255.0.0
ip route 192.213.0.0 255.255.0.0 null 0

Este ejemplo indica que el router A genera una entrada de red para 192.213.0.0/16. /16 indica que usa una superred de la dirección de clase C y que anuncia los dos primeros octetos o los primeros 16 bits.

Nota: necesita la ruta estática para que el router genere 192.213.0.0 porque la ruta estática incluye una entrada concordante en la tabla de enrutamiento.

Redistribución

El comando network es una forma de anunciar las redes mediante BGP. Otra forma es redistribuir IGP en BGP. El IGP puede ser IGRP, el protocolo Abrir trayecto más corto primero (OSPF), RIP, el Protocolo de enrutamiento de gateway interior mejorado (EIGRP) u otros protocolos. Esta redistribución puede asustar un poco porque ahora se vuelcan todas las rutas internas en BGP; se ha obtenido conocimiento de algunas de estas rutas mediante BGP y no es necesario volver a enviarlas. Aplique un filtro prudente para asegurarse de que envía a Internet sólo las rutas que desea anunciar y no todas las rutas de que las dispone. A continuación se proporciona un ejemplo:

RTA anuncia 129.213.1.0 y RTC anuncia 175.220.0.0. Observe la configuración de RTC:

bgp-toc7.gif

Si ejecuta el comando network, obtendrá lo siguiente:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500

router bgp 200
neighbor 1.1.1.1 remote-as 300
network 175.220.0.0 mask 255.255.0.0

               !--- Limita las redes que los AS originan en 175.220.0.0.
            
         

En cambio, si usa la redistribución, obtendrá lo siguiente:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500

router bgp 200
neighbor 1.1.1.1 remote-as 300
redistribute eigrp 10

               !--- EIGRP vuelve a inyectar 129.213.1.0 en BGP.
            
         

Esta redistribución hace que el AS origine 129.213.1.0. El usuario no es el origen de 129.213.1.0; lo es AS100. Debe usar filtros para evitar que el AS sea el origen de dicha red. La configuración correcta es la siguiente:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500

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

access-list 1 permit 175.220.0.0 0.0.255.255

El comando access-list se usa para controlar las redes que se originan en AS200.

La redistribución de OSPF en BGP varía ligeramente de la redistribución de otros IGP. La simple ejecución del comando redistribute ospf 1 en router bgp no funciona. Determinadas palabras clave como internal, external y nssa-external son necesarias para redistribuir las rutas respectivas. Consulte Understanding Redistribution of OSPF Routes into BGP (Introducción a la redistribución de las rutas OSPF en el BGP) para obtener más información.

Rutas estáticas y redistribución

Siempre puede usar las rutas estáticas para originar una red o una subred. La única diferencia es que BGP considera que estas rutas tienen un origen incompleto o desconocido. Puede conseguir el mismo resultado que en el ejemplo de la sección Redistribución con:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500

router bgp 200
neighbor 1.1.1.1 remote-as 300
redistribute static
...
ip route 175.220.0.0 255.255.255.0 null0
....

La interfaz null0 significa que el paquete no se toma en cuenta. Por lo tanto, si recibe el paquete y hay una coincidencia más específica que 175.220.0.0, que existe, el router envía el paquete a la específica. De lo contrario, el router no toma en cuenta el paquete. Este método es una buena manera de anunciar una superred.

En este documento se analiza el uso de diferentes métodos para originar rutas fuera del AS. Recuerde que estas rutas se generan además de otras rutas BGP cuyo conocimiento ha adquirido BGP a través de vecinos, ya sean internos o externos. BGP transfiere la información que BGP ha adquirido de un par a otros pares. La diferencia es que las rutas que se generan con el comando network, ya sean de redistribución o estáticas, indican el AS como el origen de estas redes.

La redistribución siempre es el método para inyectar BGP en IGP.

A continuación se proporciona un ejemplo:

bgp-toc8.gif

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

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

RTC#
router bgp 300
neighbor 150.10.20.1 remote-as 100
neighbor 160.10.20.1 remote-as 200
network 170.10.00

Nota: no necesita la red 150.10.0.0 o la red 160.10.0.0 en RTC a menos que desee que RTC genere estas redes y que las transfiera tal como llegan desde AS100 y AS200. La diferencia vuelve a ser que el comando network agrega un anuncio adicional para estas mismas redes, lo que indica que AS300 también es un origen para estas rutas.

Nota: recuerde que BGP no acepta actualizaciones que se hayan originado desde su propio AS. Este rechazo garantiza una topología interdominio sin bucles.

Supongamos, por ejemplo, que AS200 en el ejemplo de esta sección tiene una conexión directa BGP en AS100. RTA genera una ruta 150.10.0.0 y la envía a AS300. A continuación, RTC transfiere esta ruta a AS200 y mantiene el origen como AS100. RTB transfiere 150.10.0.0 a AS100 cuando el origen todavía es AS100. RTA se da cuenta de que la actualización se ha originado desde su AS y la omite.

iBGP

iBGP se usa si un AS desea actuar como un sistema de tránsito para otros AS. ¿Es verdad que puede hacer lo mismo si tiene conocimiento del tráfico mediante eBGP, lo redistribuye en IGP y lo vuelve a redistribuir otra vez en otro AS? Sí, pero iBGP ofrece más flexibilidad y es un método mucho más eficiente para intercambiar información dentro de un AS. iBGP ofrece métodos, por ejemplo, para controlar el mejor punto de salida del AS con el uso de la preferencia local. La sección Atributo de preferencia local proporciona más información sobre la preferencia local.

bgp-toc9.gif

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

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

RTC#
router bgp 400
neighbor 175.10.40.2 remote-as 100
network 175.10.0.0

Nota: recuerde que cuando un interlocutor BGP recibe una actualización de otros interlocutores BGP en su propio AS (iBGP), el interlocutor BGP que recibe la actualización no redistribuye esa información a otros interlocutores de su AS. El interlocutor BGP que la recibe redistribuye la información a otros interlocutores BGP fuera del AS. Por lo tanto, mantiene una interconexión completa entre los interlocutores iBGP dentro de un AS.

En el diagrama de esta sección, RTA y RTB ejecutan iBGP. RTA y RTD también ejecutan iBGP. Las actualizaciones de BGP que proceden de RTB y tienen como destino RTA se transmiten a RTE, que está fuera del AS. Las actualizaciones no se transmiten a RTD, que está dentro del AS. Por lo tanto, cree pares iBGP entre RTB y RTD para no romper el flujo de actualizaciones.

El algoritmo de decisión BGP

Después de que BGP recibe actualizaciones sobre diferentes destinos desde distintos sistemas autónomos, el protocolo debe elegir los trayectos para tener acceso a un determinado destino. BGP elige solamente un único trayecto para tener acceso a un destino.

BGP basa la decisión en diferentes atributos como salto siguiente, peso administrativo, preferencia local, origen del trayecto, longitud del trayecto, código de origen, métrica y otros.

BGP siempre propaga el mejor trayecto a los vecinos. Consulte BGP Best Path Selection Algorithm (Algoritmo de selección del mejor trayecto BGP) para obtener más información.

La sección Estudios de casos de BGP 2 explica estos atributos y su uso.

Estudios de casos de BGP 2

Atributo AS_PATH

bgp-toc10.gif

Cada vez que una actualización de ruta pasa por un sistema autónomo (AS), el número de AS se agrega a dicha actualización. El atributo AS_PATH es la lista de números de AS que una ruta atraviesa para llegar a su destino. Un atributo AS_SET es un conjunto {} ordenado matemáticamente de todos los AS que se han atravesado. La sección Ejemplo de CIDR 2 (as-set) de este documento ofrece un ejemplo de AS_SET.

En el ejemplo de esta sección, RTB anuncia la red 190.10.0.0 en AS200. Cuando dicha ruta atraviesa AS300, RTC agrega su propio número de AS a la red. Por lo tanto, cuando 190.10.0.0 llega a RTA, la red tiene dos números de AS agregados: primero 200 y después 300. Para RTA, el trayecto al que debe tener acceso 190.10.0.0 es (300, 200).

El mismo proceso se aplica a 170.10.0.0 y 180.10.0.0. RTB debe tomar el trayecto (300, 100); RTB atraviesa AS300 y después AS100 para tener acceso a 170.10.0.0. RTC debe atravesar el trayecto (200) para tener acceso a 190.10.0.0 y el trayecto (100) para tener acceso a 170.10.0.0.

Atributo de origen

El origen es un atributo obligatorio que define el origen de la información de trayecto. Este atributo puede asumir tres valores:

  • IGP: la información de accesibilidad de la capa de red (NLRI) es un atributo interno al AS de origen. Normalmente tiene lugar cuando se ejecuta el comando bgp network. Una i en la tabla BGP indica IGP.

  • EGP: la NLRI se recibe mediante el Protocolo de gateway exterior (EGP). Una e en la tabla BGP indica EGP.

  • INCOMPLETE: la NLRI se desconoce o se tiene conocimiento de ella por otros medios. INCOMPLETE tiene lugar cuando se redistribuyen rutas desde otros protocolos de enrutamiento en BGP y el origen de la ruta es incompleto. Una ? en la tabla BGP indica INCOMPLETE.

bgp-toc11.gif

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

ip route 190.10.0.0 255.255.0.0 null0

RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
network 190.10.50.0
RTE#
router bgp 300
neighbor 170.10.20.1 remote-as 100
network 170.10.0.0

RTA tiene acceso a 170.10.0.0 mediante 300 i. "300 i" significa que el próximo trayecto de AS es 300 y que el origen de la ruta es IGP. RTA también tiene acceso a 190.10.50.0 mediante i. "i" significa que la entrada se encuentra en el mismo AS y que el origen es IGP. RTE tiene acceso a 150.10.0.0 mediante 100 i. "100 i" significa que el próximo AS es 100 y que el origen es IGP. RTE también tiene acceso a 190.10.0.0 con 100 ?. "100 ?" significa que el próximo AS es 100 y que el origen es incompleto y procede de una ruta estática.

Atributo de salto siguiente de BGP

bgp-toc12.gif

El atributo del salto siguiente de BGP es la dirección IP de salto siguiente que se debe usar para tener acceso a un determinado destino.

Para eBGP, el salto siguiente siempre es la dirección IP del vecino que especifica el comando neighbor. En el ejemplo de esta sección, RTC anuncia 170.10.0.0 a RTA con un salto siguiente de 170.10.20.2. RTA anuncia 150.10.0.0 a RTC con un salto siguiente de 170.10.20.1. Para iBGP, el protocolo indica que el salto siguiente que eBGP anuncia debe llevarse a cabo en iBGP. Debido a esta regla, RTA anuncia 170.10.0.0 a su par RTB iBGP con un salto siguiente de 170.10.20.2. Por lo tanto, según RTB, el salto siguiente al que debe tener acceso 170.10.0.0 es 170.10.20.2 y no 150.10.30.1.

Asegúrese de que RTB puede tener acceso a 170.10.20.2 mediante ICP. De no ser así, RTB descarta paquetes con el destino 170.10.0.0 porque no se puede tener acceso a la dirección de salto siguiente. Por ejemplo, si RTB ejecuta iGRP, también puede ejecutar iGRP en una red RTA 170.10.0.0. iGRP debería ser pasivo en el enlace a RTC de forma que sólo se intercambie BGP.

RTA#
router bgp 100
neighbor 170.10.20.2 remote-as 300
neighbor 150.10.50.1 remote-as 100
network 150.10.0.0
RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
RTC#
router bgp 300
neighbor 170.10.20.1 remote-as 100
network 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 siguiente de BGP (redes de acceso múltiple) y Salto siguiente de BGP (NBMA) se proporcionan más detalles.

Salto siguiente de BGP (redes de acceso múltiple)

bgp-toc13.gif

Este ejemplo muestra cómo se comporta el salto siguiente en una red de acceso múltiple como Ethernet.

Supongamos que RTC y RTD en AS300 ejecutan OSPF. RTC ejecuta BGP con RTA. RTC puede tener acceso a la red 180.20.0.0 a través de 170.10.20.3. Cuando RTC envía una actualización BGP a RTA respecto a 180.20.0.0, RTC usa como salto siguiente 170.10.20.3. RTC no usa su propia dirección IP, 170.10.20.2. RTC emplea esta dirección porque la red entre RTA, RTC y RTD es una red de acceso múltiple. El uso que hace RTA de RTD como salto siguiente para tener acceso a 180.20.0.0 es más práctico que el salto adicional mediante RTC.

Nota: RTC anuncia 180.20.0.0 a RTA con un salto siguiente igual a 170.10.20.3.

Si el medio común a RTA, RTC y RTD no es de acceso múltiple, sino NBMA, pueden producirse algunas complicaciones.

Salto siguiente de BGP (NBMA)

bgp-toc14.gif

El medio común se representa como una nube en el diagrama. Si el medio común es una retransmisión de tramas o una nube de NBMA, el comportamiento exacto es como si se tuviera conexión por Ethernet. RTC anuncia 180.20.0.0 a RTA con un salto siguiente de 170.10.20.3.

El problema es que RTA no tiene un circuito virtual permanente (PVC) directo con RTD y no puede tener acceso al salto siguiente. En este caso, se produce un error en el enrutamiento.

El comando next-hop-self soluciona esta situación.

Comando next-hop-self

En situaciones con salto siguiente, como en el ejemplo de Salto siguiente de BGP (NBMA), puede usar el comando next-hop-self. La sintaxis es:

            neighbor {ip-address | peer-group-name} next-hop-self
         

El comando next-hop-self permite obligar a BGP a que use una determinada dirección IP como salto siguiente.

En el ejemplo de Salto siguiente de BGP (NBMA), esta configuración soluciona el problema:

RTC#
router bgp 300
neighbor 170.10.20.1 remote-as 100
neighbor 170.10.20.1 next-hop-self 

RTC anuncia 180.20.0.0 con un salto siguiente igual a 170.10.20.2.

Entrada posterior de BGP

bgp-toc15.gif

En este diagrama, RTA y RTC ejecutan eBGP. RTB y RTC ejecutan eBGP. RTA y RTB ejecutan algún tipo de IGP, ya sea RIP, IGRP u otro protocolo. Por definición, las actualizaciones de eBGP tienen una distancia de 20, que es menor que las distancias de IGP. Las distancias predeterminadas son:

  • 120 para RIP

  • 100 para IGRP

  • 90 para EIGRP

  • 110 para OSPF

RTA recibe actualizaciones de 160.10.0.0 mediante dos protocolos de enrutamiento:

  • eBGP con una distancia de 20

  • IGP con una distancia superior a 20

De manera predeterminada, BGP tiene las distancias siguientes:

  • Distancia externa: 20

  • Distancia interna: 200

  • Distancia local: 200

Sin embargo, puede usar el comando distance para cambiar las distancias predeterminadas:

            distance bgp external-distance internal-distance local-distance
            
         

RTA selecciona eBGP mediante RTC debido a la distancia más corta.

Si desea que RTA tenga conocimiento de 160.10.0.0 mediante RTB (IGP), tiene dos opciones:

  • Cambiar la distancia externa de eBGP o la distancia IGP.

    Nota: este cambio no se recomienda.

  • Usar la entrada posterior de BGP.

La entrada posterior de BGP hace que la ruta IGP sea la ruta preferida.

Ejecute el comando network address backdoor.

La red configurada es la red a la que desea tener acceso mediante IGP. Para BGP, esta red recibe el mismo tratamiento que una asignada localmente, a excepción de que las actualizaciones BGP no la anuncian.

RTA#
router eigrp 10

network 150.10.0.0

router bgp 100
neighbor 2.2.2.1 remote-as 300
network 160.10.0.0 backdoor 

La red 160.10.0.0 se trata como una entrada local, pero no se anuncia como una entrada de red normal.

RTA tiene conocimiento de 160.10.0.0 de RTB mediante EIGRP con una distancia de 90. RTA también tiene conocimiento de la dirección de RTC mediante eBGP con una distancia de 20. Normalmente, eBGP es la preferencia, pero debido al comando backdoor, lo es EIGRP.

Sincronización

bgp-toc16.gif

Antes de analizar la sincronización, observe la siguiente situación: RTC en AS300 envía actualizaciones de 170.10.0.0. RTA y RTB ejecutan iBGP, de manera que RTB recibe la actualización y puede tener acceso a 170.10.0.0 mediante el salto siguiente 2.2.2.1. Recuerde que el salto siguiente se ejecuta mediante iBGP. Para tener acceso al salto siguiente, RTB debe enviar el tráfico a RTE.

Supongamos que RTA no tiene una red redistribuida 170.10.0.0 en IGP. En este punto, RTE no tiene conocimiento de la existencia de 170.10.0.0.

Si RTB empieza a anunciar a AS400 que RTB puede tener acceso a 170.10.0.0, el tráfico procedente de RTD que va a RTB con destino 170.10.0.0 circula y queda descartado en RTE.

La sincronización indica que si el AS transfiere tráfico de otro AS a un tercer AS, BGP no debería anunciar una ruta antes de que todos los routers del AS tengan conocimiento de ella mediante IGP. BGP espera hasta que IGP ha propagado la ruta dentro del AS. A continuación, BGP anuncia la ruta a pares externos.

En el ejemplo de esta sección, RTB espera tener conocimiento sobre 170.10.0.0 mediante IGP. A continuación, RTB empieza a enviar la actualización a RTD. Puede hacer que RTB piense que IGP ha propagado la información si agrega una ruta estática en RTB que señale a 170.10.0.0. Asegúrese de que otros routers pueden tener acceso a 170.10.0.0.

Inhabilitación de la sincronización

En algunos casos no es necesaria la sincronización. Si no transfiere tráfico desde un AS diferente por su AS, puede inhabilitarla. También puede inhabilitarla si todos los routers del AS ejecutan BGP. La inhabilitación de esta función permite incorporar menos rutas en su IGP y que BGP confluya con mayor rapidez.

La inhabilitación no es automática. Si todos los routers del AS ejecutan BGP y no desea ejecutar IGP, el router no puede saberlo. El router espera indefinidamente una actualización de IGP de una determinada ruta antes de enviar la ruta a pares externos. En este caso, debe inhabilitar la sincronización manualmente para que el enrutamiento pueda funcionar correctamente:

router bgp 100
no synchronization

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

bgp-toc17.gif

RTB#
router bgp 100
network 150.10.0.0
neighbor 1.1.1.2 remote-as 400
neighbor 3.3.3.3 remote-as 100
no synchronization

               !--- RTB incorpora 170.10.0.0 en su tabla de enrutamiento de IP y anuncia la red
!--- a RTD, incluso si RTB no tiene un trayecto IGP hasta 170.10.0.0.
            
RTD#
router bgp 400
neighbor 1.1.1.1 remote-as 100
network 175.10.0.0

RTA#
   router bgp 100
   network 150.10.0.0
   neighbor 3.3.3.4 remote-as 100

Atributo de peso

bgp-toc18.gif

El atributo de peso es un atributo definido por Cisco. Usa el peso para seleccionar el mejor trayecto; el peso se asigna localmente al router. El valor sólo tiene sentido para el router específico y no se propaga ni se transfiere por ninguna de las actualizaciones de ruta. Un peso puede ser un número del 0 al 65.535. Los trayectos que origina el router tienen un peso predeterminado de 32.768, y otros trayectos tienen un peso de 0.

Las rutas con un valor de peso superior tienen preferencia cuando hay varias rutas en el mismo destino. Consulte el ejemplo de esta sección. RTA ha obtenido conocimiento de 175.10.0.0 mediante AS4. RTA propaga la actualización a RTC. RTB también ha obtenido conocimiento de 175.10.0.0 mediante AS4. RTB propaga la actualización a RTC. RTC tiene ahora dos formas de tener acceso a 175.10.0.0 y debe decidir el camino que debe tomar. Si define el peso de las actualizaciones en RTC que proceden de RTA de modo que sea mayor que el peso de las que proceden de RTB, está obligando a RTC a usar RTA como el salto siguiente para tener acceso a 175.10.0.0. Varios métodos consiguen esta definición de peso:

  • Use el comando neighbor.

    • neighbor {ip-address | peer-group} weight weight

  • Use listas de acceso AS_PATH.

    • ip as-path access-list access-list-number {permit | deny} as-regular-expression neighbor ip-address filter-list access-list-number weight weight

  • Use correspondencias de la ruta.

    RTC#
    router bgp 300
    neighbor 1.1.1.1 remote-as 100
    neighbor 1.1.1.1 weight 200
    
                         !--- La ruta a 175.10.0.0 de RTA tiene un peso de 200.
                      
    neighbor 2.2.2.2 remote-as 200
    neighbor 2.2.2.2 weight 100
    
                         !--- La ruta a 175.10.0.0 de RTB tiene un peso de 100.
                      
                   

RTA, que tiene un valor de peso superior, tiene preferencia como salto siguiente.

Puede conseguir el mismo resultado con IP AS_PATH y listas de filtro.

RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 filter-list 5 weight 200
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 filter-list 6 weight 100
...
ip as-path access-list 5 permit ^100$

               !--- Esto sólo permite el trayecto 100.
            
ip as-path access-list 6 permit ^200$
... 

También puede conseguir el mismo resultado con el uso de correspondencias de la ruta.

RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-map setweightin in
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 route-map setweightin in
...
ip as-path access-list 5 permit ^100$
...

route-map setweightin permit 10
match as-path 5
set weight 200

               !--- Todo lo que se aplique a la lista de acceso 5, por ejemplo, paquetes de AS100, tiene un peso de 200.
            

route-map setweightin permit 20
   set weight 100

               !--- Todo lo demás tiene un peso de 100.
            

         

Atributo de preferencia local

bgp-toc19.gif

La preferencia local es una indicación al sistema autónomo (AS) del trayecto que tiene preferencia para salir del AS con el fin de alcanzar una determinada red. Se prefiere un trayecto con una preferencia local superior. El valor predeterminado para la preferencia local es 100.

A diferencia de lo que sucede con el atributo de peso, que sólo es importante para el router local, la preferencia local es un atributo que los routers intercambian en el mismo AS.

La preferencia local se define cuando se ejecuta el comando bgp default local-preference value . También puede definir la preferencia local con las correspondencias de la ruta, como demuestra el ejemplo de esta sección:

El comando bgp default local-preference define la preferencia local en las actualizaciones que salen del router y se dirigen a los pares en el mismo AS. En el diagrama de esta sección, AS256 recibe actualizaciones de 170.10.0.0 desde dos puntos distintos de la organización. La preferencia local ayuda a determinar el camino de salida de AS256 para alcanzar dicha red. Supongamos que RTD es la preferencia de punto de salida. Esta configuración define la preferencia local para las actualizaciones que proceden de AS300 hacia 200 y para las actualizaciones que proceden de AS100 hacia 150:

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

RTD#
router bgp 256
neighbor 3.3.3.4 remote-as 300
neighbor 128.213.11.1 remote-as 256
bgp default local-preference 200

En esta configuración, RTC define la preferencia local de todas las actualizaciones en 150. El mismo RTD define la preferencia local de todas las actualizaciones en 200. Hay un intercambio de preferencia local dentro de AS256. Por consiguiente, tanto RTC como RTD se dan cuenta de que la red 170.10.0.0 tiene una preferencia local superior cuando las actualizaciones proceden de AS300 en lugar de AS100. Todo el tráfico en AS256 que tenga dicha red como destino transmite con RTD como punto de salida.

El uso de correspondencias de la ruta proporciona más flexibilidad. En el ejemplo de esta sección, todas las actualizaciones que recibe RTD se etiquetan con la preferencia local 200 cuando llegan a RTD. Las actualizaciones que proceden de AS34 también se etiquetan con la preferencia local de 200, etiqueta que puede que no sea necesaria. Por este motivo, puede usar correspondencias de la ruta para especificar las actualizaciones que se deben etiquetar con una determinada preferencia local. A continuación se proporciona un ejemplo:

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

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

route-map setlocalin permit 20
set local-preference 150 

Con esta configuración, cualquier actualización procedente de AS300 tiene una preferencia local de 200. Cualquier otra, por ejemplo, las procedentes de AS34, tienen un valor de 150.

Atributo de métrica

bgp-toc20.gif

El atributo de métrica recibe el nombre de MULTI_EXIT_DISCRIMINATOR, MED (BGP4) o INTER_AS (BGP3). El atributo es una pista para los vecinos externos sobre la preferencia de trayecto en un sistema autónomo (AS). El atributo ofrece una forma dinámica de influir en otro AS para alcanzar una cierta ruta cuando hay múltiples puntos de entrada a dicho AS. Es preferible un valor métrico inferior.

A diferencia de lo que sucede con la preferencia local, los AS intercambian la métrica. Una métrica se ejecuta en un AS, pero no lo deja. Cuando una actualización se registra en el AS con una determinada métrica, dicha métrica se usa para tomar decisiones dentro del AS. Cuando la misma actualización se transfiere a un tercer AS, la métrica vuelve a ser 0. El diagrama de esta sección muestra la configuración de la métrica. El valor predeterminado de la métrica es 0.

A menos que un router reciba otras direcciones, él mismo compara la métrica de los trayectos de los vecinos en el mismo AS. Para que el router compare las métricas de los vecinos que proceden de diferentes AS, debe ejecutar el comando de configuración especial bgp always-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 garantiza la comparación de la variable MED en la elección de ruta cuando diferentes pares se anuncian en el mismo AS. Si se ejecuta el comando bgp always-compare-med, se garantiza la comparación de MED para los trayectos de vecinos en diferentes AS. El comando bgp always-compare-med es de utilidad cuando múltiples proveedores de servicios o empresas acuerdan una política uniforme para configurar MED. Consulte How the bgp deterministic-med Command Differs from the bgp always-compare-med Command (En qué se diferencia el comando bgp 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 RTD están en AS300, y RTB en AS400.

Supongamos que ha establecido la métrica que procede de RTC en 120, la que procede de RTD en 200 y la que procede de RTB en 50. De manera predeterminada, un router compara la métrica que procede de los vecinos en el mismo AS. Por lo tanto, RTA sólo puede comparar la métrica que procede de RTC con la que procede de RTD. RTA selecciona a RTC como el mejor salto siguiente porque 120 es menor que 200. Cuando RTA recibe una actualización de RTB con la métrica 50, no puede comparar la métrica con 120 porque RTC y RTB están en AS diferentes. RTA debe seleccionar en función de otros atributos.

Para obligar a RTA a que compare las métricas, debe ejecutar el comando bgp always-compare-med en RTA. Las configuraciones siguientes muestran este proceso:

RTA#
   router bgp 100
   neighbor 2.2.2.1 remote-as 300
   neighbor 3.3.3.3 remote-as 300
   neighbor 4.4.4.3 remote-as 400
   ....

RTC#
   router bgp 300
   neighbor 2.2.2.2 remote-as 100
   neighbor 2.2.2.2 route-map setmetricout out
   neighbor 1.1.1.2 remote-as 300

route-map setmetricout permit 10
   set metric 120

RTD#
   router bgp 300
   neighbor 3.3.3.2 remote-as 100
   neighbor 3.3.3.2 route-map setmetricout out
   neighbor 1.1.1.1 remote-as 300

route-map setmetricout permit 10
   set metric 200

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

route-map setmetricout permit 10
   set metric 50

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

RTA#
router bgp 100
neighbor 2.2.21 remote-as 300
neighbor 3.3.3.3 remote-as 300
neighbor 4.4.4.3 remote-as 400
bgp always-compare-med

En este caso, RTA selecciona a RTB como el mejor salto siguiente para tener acceso a la red 180.10.0.0.

También puede definir la métrica durante la redistribución de las rutas en BGP si ejecuta el comando default-metric number .

Supongamos que en el ejemplo de esta sección, RTB inyecta una red por medio de un valor estático en AS100. Aquí está la configuración:

RTB#
router bgp 400
redistribute static
default-metric 50

ip route 180.10.0.0 255.255.0.0 null 0

               !--- Hace que RTB envíe 180.10.0.0 con un métrica de 50.
            
         

Atributo de comunidad

El atributo de comunidad es un atributo transitivo y optativo en el intervalo de 0 a 4.294.967.200. Este atributo es una forma de agrupar destinos en una determinada comunidad y de aplicar decisiones de enrutamiento según estas comunidades. Las decisiones de enrutamiento son, entre otras, aceptar, preferir y redistribuir.

Puede usar las correspondencias de la ruta para establecer los atributos de la comunidad. El comando de la correspondencia de la ruta set tiene la sintaxis siguiente:

            set community community-number [additive] [well-known-community] 
         

Algunas comunidades predefinidas y conocidas para usar en este comando son:

  • no-export: no anuncie a pares eBGP. Mantenga esta ruta dentro de un AS.

  • no-advertise: no anuncie esta ruta a ningún par interno o externo.

  • internet: anuncie esta ruta a la comunidad de Internet. Cualquier router pertenece a esta comunidad.

  • local-as: se usa en escenarios de confederación para evitar la transmisión de paquetes fuera del AS local.

A continuación se presentan dos ejemplos de correspondencias de la ruta que definen la comunidad:

  • route-map communitymap
    match ip address 1
    set community no-advertise

    o

  • route-map setcommunity
    match as-path 1
    set community 200 additive 

Si no define la palabra clave additive, 200 sustituye cualquier comunidad anterior que ya exista. Si usa la palabra clave additive, se produce una adición de 200 a la comunidad. Aunque defina el atributo de comunidad, éste no se transmite a los vecinos de forma predeterminada. Para enviarlo a un vecino, debe usar el comando siguiente:

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

A continuación se proporciona un ejemplo:

RTA#
router bgp 100
neighbor 3.3.3.3 remote-as 300
neighbor 3.3.3.3 send-community
neighbor 3.3.3.3 route-map setcommunity out

En la versión 12.0 y posteriores del software Cisco IOS, puede configurar comunidades en tres formatos diferentes: decimal, hexadecimal y AA:NN. De forma predeterminada, el software Cisco IOS usa el formato decimal anterior. Para configurar y mostrar en formato AA:NN, ejecute el comando ip bgp-community new-format de configuración global. La primera parte de AA:NN representa el número de AS, y la segunda, un número de 2 bytes.

A continuación se proporciona un ejemplo:

Sin el comando ip bgp-community new-format en la configuración global, al ejecutar el comando show ip bgp 6.0.0.0 se muestra el valor del atributo de comunidad en formato decimal. En este ejemplo, el valor del atributo de comunidad aparece como 6553620.

Router# show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/8, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  1
    10.10.10.1 from 10.10.10.1 (200.200.200.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 6553620

         

Ahora, ejecute el comando ip bgp-community new-format globalmente en este router.

Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# ip bgp-community new-format
Router(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 se muestra como 100:20 en el resultado del comando show ip bgp 6.0.0.0 de este ejemplo:

Router# show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/8, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  1
    10.10.10.1 from 10.10.10.1 (200.200.200.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 100:20
         

Estudios de casos de BGP 3

Filtrado de BGP

Varios métodos de filtrado distintos permiten controlar el envío y la recepción de las actualizaciones BGP. Puede filtrar las actualizaciones BGP con información de ruta como base, o con información de trayecto o de comunidades como base. Todos los métodos consiguen los mismos resultados. La elección de uno sobre otro depende de la configuración de red específica.

Filtrado de ruta

bgp-toc21.gif

Para limitar la información de enrutamiento que el router anuncia o de la que tiene conocimiento, puede filtrar BGP con actualizaciones de enrutamiento a o desde un determinado vecino. Puede definir una lista de acceso y aplicarla a las actualizaciones que proceden o que están destinadas a un vecino. Ejecute el comando siguiente en el modo de configuración del router:

            neighbor {ip-address | peer-group-name} distribute-list access-list-number {in | out}

         

En este ejemplo, RTB se origina en la red 160.10.0.0 y envía la actualización a RTC. Si RTC desea detener la propagación de las actualizaciones a AS100, debe definir una lista de acceso para filtrar dichas actualizaciones y aplicarla durante la comunicación con RTA:

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

access-list 1 deny 160.10.0.0 0.0.255.255

access-list 1 permit 0.0.0.0 255.255.255.255

               !--- Filtrar todas las actualizaciones de enrutamiento de 160.10.x.x.
            
         

El uso de listas de acceso es un poco difícil cuando se trabaja con superredes que pueden provocar algunos conflictos.

Supongamos que, en el ejemplo de esta sección, RTB tiene subredes diferentes de 160.10.x.x. El objetivo es filtrar actualizaciones y anunciar solamente 160.0.0.0/8.

Nota: la anotación /8 significa que usa 8 bits de máscara de subred, que comienza a la izquierda de la dirección IP. Esta dirección es equivalente a 160.0.0.0 255.0.0.0.

El comando access-list 1 permit 160.0.0.0. 0.255.255.255 permite 160.0.0.0/8, 160.0.0.0/9, etc. Para limitar la actualización a 160.0.0.0/8 solamente, debe usar una lista de acceso ampliada del formato siguiente:

            access-list 101 permit ip 160.0.0.0 0.255.255.255 255.0.0.0 0.0.0.0.
         

Esta lista sólo permite 160.0.0.0/8.

Consulte How to Block One or More Networks From a BGP Peer (Bloqueo de una o más redes desde un par BGP) para obtener ejemplos de configuraciones sobre cómo filtrar redes desde pares BGP. El método usa el comando distribute-list con listas de control de acceso (ACL) estándar y ampliadas, así como filtros de lista de prefijos.

Filtrado de trayecto

Otro tipo de filtrado es el filtrado de trayecto.

bgp-toc22.gif

Puede especificar una lista de acceso en las actualizaciones de entrada y salida si usa la información de trayecto del AS BGP. En el diagrama de esta sección, puede bloquear las actualizaciones de 160.10.0.0 de modo que no se transfieran a AS100. Para ello, defina una lista de acceso en RTC que impida la transmisión a AS100 de cualquier actualización que se haya originado desde AS200. Ejecute los comandos siguientes:

            ip as-path access-list access-list-number {permit | deny} as-regular-expression
            

         
            neighbor {ip-address | peer-group-name} filter-list access-list-number {in | out}
         

Este ejemplo detiene el envío de RTC de actualizaciones de 160.10.0.0 a RTA:

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

               !--- 1 es el número de lista de acceso que se indica abajo.
            
ip as-path access-list 1 deny ^200$
ip as-path access-list 1 permit .*

El comando access-list 1 de este ejemplo obliga a denegar cualquier actualización con información de trayecto que se inicie con 200 y termine con 200. ^200$ en el comando es una "expresión normal", en la que ^ significa "empieza por" y $ significa "termina por". Dado que RTB envía actualizaciones de 160.10.0.0 con información de trayecto que comienza con 200 y termina con 200, las actualizaciones coinciden con la lista de acceso. La lista de acceso deniega estas actualizaciones.

La entrada .* es otra expresión normal en la que . significa "cualquier carácter" y * significa "la repetición de dicho carácter". Por lo tanto, .* representa cualquier información de trayecto, que es necesaria para permitir la transmisión de todas las otras actualizaciones.

¿Qué sucede si en lugar de usar ^200$, usa ^200? Con un AS400, como en el diagrama de esta sección, las actualizaciones que origina AS400 tienen información de trayecto del tipo (200, 400). En esta información de trayecto, 200 es el primero y 400, el último. Estas actualizaciones concuerdan con la lista de acceso ^200 porque la información de trayecto empieza por 200. La lista de acceso impide la transmisión de estas actualizaciones a RTA, lo que no es un requisito.

Para verificar si ha implementado la expresión normal correcta, ejecute el comando show ip bgp regexp regular-expression . Este comando muestra todos los trayectos que han coincidido con la configuración de la expresión normal.

Expresión normal de AS

Esta sección explica la creación de una expresión normal.

Una expresión normal es un patrón que debe coincidir con una cadena de entrada. Cuando crea una expresión normal, especifica una cadena que debe coincidir con la entrada. En el caso de BGP, especifica una cadena que consta de información de trayecto que debe coincidir con una entrada.

En el ejemplo de la sección Filtrado de trayecto, especificó la cadena ^200$. Deseaba que la información de trayecto que incorporan las actualizaciones coincidiera con la cadena para tomar una decisión.

Una expresión normal comprende:

  • Rango

    Un rango es una secuencia de caracteres dentro de corchetes. Un ejemplo es [abcd].

  • Átomo

    Un átomo es un único carácter. A continuación se muestran algunos ejemplos:

    .
    • El símbolo . coincide con cualquier único carácter.

    ^
    • El símbolo ^ coincide con el inicio de la cadena de entrada.

    $
    • El símbolo $ coincide con el final de la cadena de entrada.

    \
    • El símbolo \ coincide con el carácter.

    -
    • El símbolo _ coincide con coma (,), corchete redondo izquierdo ({), corchete redondo derecho (}), inicio de la cadena de entrada, final de la cadena de entrada o espacio.

  • Pieza

    Una pieza es uno de estos símbolos, que sigue a un átomo:

    *
    • El símbolo * coincide con 0 o más secuencias del átomo.

    +
    • El símbolo + coincide con 1 o más secuencias del átomo.

    ?
    • El símbolo ? coincide con el átomo o con la cadena nula.

  • Rama

    Una rama es 0 o más piezas concatenadas.

A continuación se incluyen algunos ejemplos de expresiones normales:

a*
  • Esta expresión indica cualquier aparición de la letra "a", ninguna inclusive.

a+
  • Esta expresión indica que, como mínimo, debe haber un caso de letra "a".

ab?a
  • Esta expresión coincide con "aa" o "aba".

_100_
  • Esta expresión significa mediante AS100.

_100$
  • Esta expresión indica un origen de AS100.

^100 .*
  • Esta expresión indica una transmisión de AS100.

^$
  • Esta expresión indica un origen de este AS.

Consulte Using Regular Expressions in BGP (Uso de expresiones normales en BGP) para obtener ejemplos de configuraciones de filtrado de expresiones normales.

Filtrado de comunidad BGP

Este documento ha analizado el filtrado de ruta y el filtrado de trayecto AS. Otro método es el filtrado de comunidad. En la sección Atributo de comunidad se analiza la comunidad y se proporcionan algunos ejemplos de cómo usarla.

bgp-toc23.gif

En este ejemplo, desea que RTB defina el atributo de comunidad en las rutas BGP que RTB anuncia, de modo que RTC no las propague a pares externos. Use el atributo de comunidad no-export.

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

route-map setcommunity
match ip address 1
set community no-export

access-list 1 permit 0.0.0.0 255.255.255.255 

Nota: este ejemplo utiliza el comando route-map setcommunity para definir la comunidad como no-export.

Nota: el comando neighbor send-community es necesario para enviar este atributo a RTC.

Cuando RTC recibe las actualizaciones con el atributo NO_EXPORT, no las propaga a un RTA de par externo.

En este ejemplo, RTB ha definido el atributo de comunidad en 100 200 additive. Esta acción agrega el valor 100 200 a cualquier valor de comunidad existente antes de la transmisión a RTC.

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

route-map setcommunity
match ip address 2
set community 100 200 additive

access-list 2 permit 0.0.0.0 255.255.255.255 

Una lista de comunidad es un grupo de comunidades que se usan en una cláusula match de una correspondencia de la ruta. La lista de comunidades permite filtrar o definir atributos con listas diferentes de números de comunidad como base.

            ip community-list community-list-number {permit | deny} community-number
            
         

Por ejemplo, puede definir esta correspondencia de la ruta, match-on-community:

route-map match-on-community
match community 10

               !--- El número de la lista de comunidades es 10.
            
set weight 20
ip community-list 10 permit 200 300

               !--- El número de comunidad es 200 300.
            

         

Puede usar la lista de comunidades para filtrar o definir ciertos parámetros, como peso y métrica, en algunas actualizaciones con el valor de la comunidad como base. En el segundo ejemplo de esta sección, RTB envía actualizaciones a RTC con una comunidad de 100 200. Si RTC desea definir el peso con dichos valores como base, puede hacer lo siguiente:

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

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

route-map check-community permit 20
match community 2 exact
set weight 10

route-map check-community permit 30
match community 3

ip community-list 1 permit 100
ip community-list 2 permit 200
ip community-list 3 permit internet 

En este ejemplo, cualquier ruta que tenga 100 en el atributo de comunidad coincide con la lista 1. El peso de esta ruta se define en 20. Cualquier ruta que tenga solamente 200 como comunidad, coincide con la lista 2 y tiene un peso de 20. La palabra clave exact indica que la comunidad consta de 200 y de nada más. La última lista de comunidades que se presenta aquí es para garantizar que no se descartan otras actualizaciones. Recuerde que, como valor predeterminado, todo lo que no coincide se descarta. La palabra clave internet indica todas las rutas porque todas son miembros de la comunidad de Internet.

Consulte Using BGP Community Values to Control Routing Policy in an Upstream Provider Network (Uso de los valores de la comunidad BGP para controlar la política de enrutamiento en una red de proveedor ascendente) para obtener más información.

Vecinos y correspondencias de la ruta BGP

bgp-toc24.gif

Puede usar el comando neighbor con las correspondencias de la ruta para filtrar o definir parámetros sobre actualizaciones de entrada y salida.

Las correspondencias de la ruta asociadas con la sentencia neighbor no tienen ningún efecto sobre las actualizaciones de entrada cuando la coincidencia se efectúa en función de la dirección IP:

            neighbor ip-address route-map route-map-name
            
         

Supongamos que en el diagrama de esta sección desea que RTC tenga conocimiento por parte de AS200 de las redes que son locales a AS200 y nada más. Asimismo, desea definir el peso de las rutas aceptadas en 20. Use una combinación de listas de acceso neighbor y as-path:

RTC#
   router bgp 300
   network 170.10.0.0
   neighbor 3.3.3.3 remote-as 200
   neighbor 3.3.3.3 route-map stamp in

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

ip as-path access-list 1 permit ^200$ 

Cualquier actualización que se origine en AS200 tiene información de trayecto que comienza con 200 y finaliza con 200. Estas actualizaciones están permitidas. Se descarta cualquier otra actualización.

Supongamos que desea lo siguiente:

  • Que se acepten las actualizaciones que se originan en AS200 y que tienen un peso de 20

  • Que se descarten las actualizaciones que se originan en AS400

  • Un peso de 10 para las otras actualizaciones

    RTC#
    router bgp 300
    network 170.10.0.0
    neighbor 3.3.3.3 remote-as 200
    neighbor 3.3.3.3 route-map stamp in
    
    route-map stamp permit 10
    match as-path 1
    set weight 20
    
    route-map stamp permit 20
    match as-path 2
    set weight 10
    
    ip as-path access-list 1 permit ^200$
    ip as-path access-list 2 permit ^200 600 .*

    Esta sentencia define un peso de 20 para las actualizaciones que son locales de AS200. También define un peso de 10 para las actualizaciones que están detrás de AS400 y descarta las que proceden de AS400.

Uso del comando set as-path prepend

En algunas situaciones, debe modificar la información de trayecto para manipular el proceso de decisión de BGP. El comando que se usa con una correspondencia de la ruta es:

            set as-path prepend as-path#
               as-path#
            
         

Supongamos que en el diagrama de la sección Vecinos y correspondencias de la ruta BGP, RTC anuncia su propia red 170.10.0.0 a dos sistemas autónomos (AS) diferentes, AS100 y AS200. Cuando la información se propaga a AS600, los routers de AS600 tienen información de accesibilidad de la red de 150.10.0.0 por dos rutas diferentes. La primera ruta es por AS100 con el trayecto (100, 300) y la segunda es por AS400 con el trayecto (400, 200, 300). Si todos los demás atributos son los mismos, AS600 selecciona el trayecto más corto y elige la ruta por AS100.

AS300 recibe todo el tráfico por AS100. Si desea influir en esta decisión desde el extremo de AS300, puede hacer que el trayecto que pasa por AS100 parezca más largo que el trayecto que pasa por AS400. Para ello, agregue números de AS a la información de trayecto existente que se anuncia en AS100. Una práctica común es repetir el propio número de AS de la forma siguiente:

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

route-map SETPATH
set as-path prepend 300 300

Debido a esta configuración, AS600 recibe actualizaciones de 170.10.0.0 por AS100 con información de trayecto de: (100, 300, 300, 300). Esta información de trayecto es más larga que la información (400, 200, 300) que AS600 ha recibido de AS400.

Grupos de pares BGP

bgp-toc25.gif

Un grupo de pares es un grupo de vecinos BGP con las mismas políticas de actualización. Las correspondencias de la ruta, las listas de distribución y las listas de filtrado definen habitualmente dichas políticas. No se definen las mismas para cada vecino, sino que se define un nombre de grupo de pares y se le asignan estas políticas.

Los miembros del grupo de pares heredan todas las opciones de configuración del grupo de pares. También puede configurar miembros para anular estas opciones, si éstas no afectan a las actualizaciones de salida. Sólo puede anular opciones que se hayan definido en la entrada.

Para definir un grupo de pares, ejecute el comando siguiente:

            neighbor peer-group-name peer-group
         

Este ejemplo aplica grupos de pares a vecinos BGP internos y externos:

RTC#
   router bgp 300
   neighbor internalmap peer-group
   neighbor internalmap remote-as 300
   neighbor internalmap route-map SETMETRIC out
   neighbor internalmap filter-list 1 out
   neighbor internalmap filter-list 2 in
   neighbor 5.5.5.2 peer-group internalmap
   neighbor 5.6.6.2 peer-group internalmap
   neighbor 3.3.3.2 peer-group internalmap
   neighbor 3.3.3.2 filter-list 3 in

Esta configuración define un grupo de pares con el nombre internalmap. La configuración establece algunas políticas para el grupo, como una correspondencia de la ruta SETMETRIC para definir la métrica en 5, y dos listas de filtros diferentes, 1 y 2. La configuración aplica el grupo de pares a todos los vecinos internos, RTE, RTF y RTG. La configuración establece también una lista de filtros 3 distinta para el vecino RTE. Esta lista de filtros anula la lista de filtros 2 dentro del grupo de pares.

Nota:  sólo puede anular opciones que afectan a las actualizaciones de entrada.

Ahora, observe cómo puede usar grupos de pares con vecinos externos. Con el mismo diagrama de esta sección, configure RTC con un grupo de pares externalmap y aplique el grupo de pares a los vecinos externos.

RTC#
   router bgp 300
   neighbor externalmap peer-group
   neighbor externalmap route-map SETMETRIC
   neighbor externalmap filter-list 1 out
   neighbor externalmap filter-list 2 in
   neighbor 2.2.2.2 remote-as 100
   neighbor 2.2.2.2 peer-group externalmap
   neighbor 4.4.4.2 remote-as 600
   neighbor 4.4.4.2 peer-group externalmap
   neighbor 1.1.1.2 remote-as 200
   neighbor 1.1.1.2 peer-group externalmap
   neighbor 1.1.1.2 filter-list 3 in

Nota: en estas configuraciones, se definen las sentencias remote-as fuera del grupo de pares porque se deben establecer distintos AS externos. Anule también las actualizaciones de entrada del vecino 1.1.1.2 con la asignación de la lista de filtros 3.

Si desea obtener más información sobre los grupos de pares, consulte BGP Peer Groups (Grupos de pares BGP).

Nota: en la versión 12.0(24)S del software Cisco IOS, Cisco introdujo la función de actualización automática de grupos de pares BGP. Esta función se encuentra también disponible en versiones posteriores del software Cisco IOS. La función introduce un nuevo algoritmo que calcula y optimiza dinámicamente grupos de actualización de los vecinos que comparten las mismas políticas de salida. Estos vecinos pueden compartir los mismos mensajes de actualización. En versiones anteriores de Cisco IOS, el grupo de mensajes de actualización de BGP era la base de las configuraciones del grupo de pares. Este método para agrupar actualizaciones limitaba las políticas de salida y las configuraciones de sesión específicas. La función de actualización dinámica de grupos de pares de BGP separa la réplica del grupo de actualización de la configuración del grupo de pares. Esta separación mejora el tiempo de convergencia y la flexibilidad de la configuración del vecino. Consulte BGP Dynamic Update Peer-Groups (Grupos de pares de actualización dinámica BGP) para obtener más información.

Estudios de casos de BGP 4

CIDR y direcciones de agrupación

bgp-toc26.gif

Una de las principales mejoras de BGP4 en relación con BGP3 es el enrutamiento interdominio sin clase (CIDR). CIDR o superredes es una nueva forma de considerar las direcciones IP. Con CIDR, no hay ninguna noción de clases, como clase A, B o C. La red 192.213.0.0, por ejemplo, fue en su día una red de clase C ilegal. Ahora, la red es una superred legal, 192.213.0.0/16. "16" representa el número de bits de la máscara de subred, si cuenta desde la izquierda de la dirección IP. Esta representación es similar a 192.213.0.0 255.255.0.0.

Las agrupaciones se usan para minimizar el tamaño de las tablas de enrutamiento. La agrupación es el proceso que combina las características de varias rutas diferentes de forma que sólo es posible el anuncio de una sola. En este ejemplo, RTB genera la red 160.10.0.0. RTC se configura para propagar una superred de dicha ruta 160.0.0.0 en RTA:

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

#RTC
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
network 170.10.0.0
aggregate-address 160.0.0.0 255.0.0.0 

RTC propaga la dirección de agrupación 160.0.0.0 a RTA.

Comandos aggregate

Hay una amplia gama de comandos aggregate. Debe comprender cómo funcionan todos si desea conseguir el comportamiento adecuado de la agrupación.

El primer comando se muestra en el ejemplo de la sección CIDR y direcciones de agrupación:

            aggregate-address address-mask
            
         

Este comando anuncia la ruta del prefijo y las rutas más específicas. El comando aggregate-address 160.0.0.0 propaga una red adicional 160.0.0.0, pero no impide la propagación de 160.10.0.0 a RTA. El resultado es la propagación de las dos redes, 160.0.0.0 y 160.10.0.0, a RTA, que es el anuncio de la ruta del prefijo y de la ruta más específica.

Nota: no puede agregar una dirección si no tiene una ruta más específica de dicha dirección en la tabla de enrutamiento BGP.

RTB no puede generar, por ejemplo, una agrupación para 160.0.0.0 si no tiene una entrada más específica de 160.0.0.0 en la tabla BGP. Se puede efectuar una inyección de rutas más específicas en dicha tabla. La inyección de rutas puede tener lugar mediante:

  • Actualizaciones de entrada de otros AS.

  • La redistribución de un IGP o valor estático en BGP

  • El comando network, por ejemplo, network 160.10.0.0

Si desea que RTC propague solamente la red 160.0.0.0 y no la ruta más específica, ejecute el comando siguiente:

            aggregate-address address mask summary-only
         

Este comando anuncia el prefijo solamente y suprime todas las rutas más específicas.

El comando aggregate 160.0.0.0 255.0.0.0. summary-only propaga la red 160.0.0.0 y suprime la ruta más específica 160.10.0.0.

Nota: si agrega una ruta que se inyectó en BGP por la sentencia network, la entrada de red se inyecta siempre en actualizaciones de BGP. Esta inyección tiene lugar aunque use el comando aggregate summary-only. El ejemplo de la sección Ejemplo de CIDR 1 analiza esta situación.

            aggregate-address address-mask as-set
         

Este comando anuncia la ruta del prefijo y las rutas más específicas. Pero el comando incluye as-set en la información de trayecto de las actualizaciones de enrutamiento.

            aggregate 129.0.0.0 255.0.0.0 as-set
         

La sección Ejemplo de CIDR 2 (as-set) analiza este comando.

Si desea suprimir rutas más específicas cuando efectúa la agrupación, defina una correspondencia de la ruta y aplíquela a las agrupaciones. Esta acción permite seleccionar las rutas más específicas que se deben suprimir.

            aggregate-address address-mask suppress-map map-name
            
         

Este comando anuncia la ruta del prefijo y las rutas más específicas. Pero el comando suprime el anuncio con una base de correspondencia de la ruta. Supongamos que con el diagrama de la sección CIDR y direcciones de agrupación desea agregar 160.0.0.0, suprimir la ruta más específica 160.20.0.0 y permitir la propagación de 160.10.0.0. Use la correspondencia de la ruta siguiente:

route-map CHECK permit 10
match ip address 1

access-list 1 permit 160.20.0.0 0.0.255.255
access-list 1 deny 0.0.0.0 255.255.255.255

Por la definición de suppress-map, se suprime de las actualizaciones cualquier paquete que permita la lista de acceso.

A continuación, aplique la correspondencia de la ruta a la sentencia aggregate.

RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 remote-as 100
network 170.10.0.0
aggregate-address 160.0.0.0 255.0.0.0 suppress-map CHECK 

Aquí tiene otra variación:

            aggregate-address address-mask attribute-map map-name
            
         

Este comando permite definir los atributos, como la métrica, en el momento de enviar las agrupaciones. Para definir el origen de las agrupaciones en IGP, aplique la correspondencia de la ruta siguiente al comando aggregate attribute-map:

route-map SETMETRIC
set origin igp

aggregate-address 160.0.0.0 255.0.0.0 attribute-map SETORIGIN

Si desea obtener más información, consulte Understanding Route Aggregation in BGP (Introducción a la agrupación de rutas en BGP).

Ejemplo de CIDR 1

bgp-toc27.gif

Solicitud: permitir a RTB que anuncie el prefijo 160.0.0.0 y que suprima todas las rutas más específicas. El problema de esta solicitud es que la red 160.10.0.0 es local de AS200, lo que significa que AS200 es quien la origina. No puede hacer que RTB genere un prefijo para 160.0.0.0 sin generar una entrada para 160.10.0.0, aunque use el comando aggregate summary-only. RTB genera las dos redes porque RTB es quien origina 160.10.0.0. Hay dos soluciones para este problema.

La primera es usar una ruta estática y redistribuirla en BGP. El resultado es que RTB anuncia la agrupación con un origen incompleto (?).

RTB#
router bgp 200
neighbor 3.3.3.1 remote-as 300
redistribute static

               !--- Genera una actualización para 160.0.0.0
!--- con el trayecto de origen como incompleto.
            
ip route 160.0.0.0 255.0.0.0 null0

En la segunda solución, además de la ruta estática, se agrega una entrada para el comando network. Esta entrada tiene el mismo efecto, con la diferencia de que define el origen de la actualización en IGP.

RTB#
router bgp 200
network 160.0.0.0 mask 255.0.0.0

               !--- Esta entrada marca la actualización con el origen IGP.
            
neighbor 3.3.3.1 remote-as 300
redistribute static
ip route 160.0.0.0 255.0.0.0 null0 

Ejemplo de CIDR 2 (as-set)

Use la sentencia as-set en la agrupación para reducir el tamaño de la información de trayecto. Con as-set, el número de AS se enumera sólo una vez, independientemente de la cantidad de veces que aparece en los múltiples trayectos agregados. El comando aggregate as-set se usa en situaciones en las que la agrupación de la información provoca la pérdida de datos respecto al atributo de trayecto. En este ejemplo, RTC recibe la actualización sobre 160.20.0.0 de RTA y actualiza 160.10.0.0 a partir de RTB. Supongamos que RTC desea agregar la red 160.0.0.0/8 y enviarla a RTD. RTD desconoce el origen de dicha ruta. Si agrega la sentencia aggregate as-set, está obligando a RTC a generar información de trayecto en la forma de un conjunto {}. Dicho conjunto incluye toda la información de trayecto, independientemente de cual fuera el primer trayecto.

bgp-toc28.gif

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

RTA#
router bgp 100
network 160.20.0.0
neighbor 2.2.2.1 remote-as 300

Caso 1:

RTC no tiene una sentencia as-set. RTC envía una actualización de 160.0.0.0/8 a RTD con la información de trayecto (300), como si la ruta se hubiera originado desde AS300.

RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 4.4.4.4 remote-as 400
aggregate 160.0.0.0 255.0.0.0 summary-only

               !--- Este comando hace que RTC envíe las actualizaciones de RTD de 160.0.0.0/8
!--- sin ninguna indicación de que 160.0.0.0 procede de dos AS diferentes.
!--- Esto puede crear bucles si RTD tiene una entrada de nuevo en AS100 o AS200. 
            
         

Caso 2:

RTC#
   router bgp 300
   neighbor 3.3.3.3 remote-as 200
   neighbor 2.2.2.2 remote-as 100
   neighbor 4.4.4.4 remote-as 400
   aggregate 160.0.0.0 255.0.0.0 summary-only
   aggregate 160.0.0.0 255.0.0.0 as-set

               !--- Este comando hace que RTC envíe las actualizaciones de RTD de 160.0.0.0/8
  !--- con una indicación de que 160.0.0.0 pertenece a un conjunto {100 200}.  
            
         

Los dos siguientes temas, Confederación de BGP y Reflectores de ruta, van destinados a proveedores de servicios de Internet (ISP) que desean un control más exhaustivo de la explosión de pares BGP dentro de sus AS.

Confederación de BGP

La implementación de la confederación de BGP reduce la interconexión de iBGP dentro de un sistema autónomo (AS). El truco está en dividir un AS en varios otros y asignar el grupo completo a una única confederación. Cada AS tiene su iBGP totalmente interconectado y conexiones a otros AS dentro de la confederación. Aunque estos AS tienen pares eBGP en los AS incluidos en la confederación, intercambian enrutamientos como si usaran iBGP. De esta forma, la confederación conserva la información sobre el salto siguiente, la métrica y la preferencia local. Para el mundo exterior, la confederación parece como un único AS.

Para configurar una confederación BGP, use el comando siguiente:

            bgp confederation identifier autonomous-system
            
         

El identificador de confederación es el número de AS del grupo de la confederación.

Si ejecuta este comando, se crean pares entre varios AS dentro de la confederación:

            bgp confederation peers autonomous-system [autonomous-system] 

         

A continuación se incluye un ejemplo de confederación:

bgp-toc29.gif

Supongamos que tiene un AS500 que consta de nueve interlocutores BGP. También existen otros interlocutores que no son BGP, pero sólo hay interés por los interlocutores BGP que tienen conexiones eBGP con otros AS. Si desea crear una interconexión de iBGP completa dentro de AS500, necesita nueve conexiones pares para cada router. Necesita ocho pares iBGP y un par eBGP a AS externos.

Si usa la confederación, puede dividir AS500 en varios AS: AS50, AS60 y AS70. El AS recibe un identificador de confederación 500. El mundo exterior sólo ve un AS, AS500. Para cada AS50, AS60 y AS70, puede definir una interconexión completa de pares iBGP y la lista de pares de confederación con el comando bgp confederation peers.

A continuación se presenta una configuración de ejemplo de routers RTC, RTD y RTA:

Nota: RTA desconoce la existencia de AS50, AS60 y AS70. RTA sólo tiene conocimiento de AS500.

RTC#
router bgp 50
bgp confederation identifier 500
bgp confederation peers 60 70
neighbor 128.213.10.1 remote-as 50 (IBGP connection within AS50)
neighbor 128.213.20.1 remote-as 50 (IBGP connection within AS50)
neighbor 129.210.11.1 remote-as 60 (BGP connection with confederation peer 60)
neighbor 135.212.14.1 remote-as 70 (BGP connection with confederation peer 70)
neighbor 5.5.5.5 remote-as 100 (EBGP connection to external AS100)

RTD#
router bgp 60
bgp confederation identifier 500
bgp confederation peers 50 70
neighbor 129.210.30.2 remote-as 60 (IBGP connection within AS60)
neighbor 128.213.30.1 remote-as 50(BGP connection with confederation peer 50)
neighbor 135.212.14.1 remote-as 70 (BGP connection with confederation peer 70)
neighbor 6.6.6.6 remote-as 600 (EBGP connection to external AS600)

RTA#
   router bgp 100
   neighbor 5.5.5.4 remote-as 500 (EBGP connection to confederation 500)

Reflectores de ruta

Otra solución para la explosión de pares iBGP dentro de un AS son los reflectores de ruta (RR). Tal como demuestra la sección iBGP, un interlocutor BGP no anuncia una ruta cuya existencia conoció por otro interlocutor iBGP a un tercer interlocutor iBGP. Puede relajar un poco esta restricción y proporcionar control adicional, que permite a un router anunciar, o reflejar, las rutas cuyo conocimiento ha adquirido iBGP a otros interlocutores iBGP. Este reflejo de ruta reduce el número de pares iBGP dentro de un AS.

bgp-toc30.gif

En casos normales, mantenga una interconexión iBGP completa entre RTA, RTB y RTC dentro de AS100. Si usa el concepto RR, RTC se puede elegir como un RR. De esta forma, RTC tiene un par parcial iBGP con RTA y RTB. Los pares entre RTA y RTB no son necesarios porque RTC es un RR para las actualizaciones que proceden de RTA y RTB.

            neighbor route-reflector-client
         

El router con este comando es el RR, y los vecinos a los que apunta el comando son los clientes de dicho RR. En el ejemplo, la configuración RTC tiene el comando neighbor route-reflector-client que apunta a las direcciones IP de RTA y RTB. La combinación de RR y de clientes es un "agrupamiento". En este ejemplo, RTA, RTB y RTC forman un agrupamiento con un único RR dentro de AS100.

Otros pares iBGP de RR que no son clientes son "no clientes".

bgp-toc31.gif

Un AS puede tener más de un RR. En esta situación, un RR trata a otros RR como cualquier otro interlocutor iBGP. Otros RR pueden pertenecer al mismo agrupamiento (grupo de clientes) o a otros. En una configuración sencilla, puede dividir el AS en varios agrupamientos. Cada RR se configura con otros RR como pares no clientes en una topología completamente interconectada. Los clientes no deben crear pares con interlocutores iBGP fuera del agrupamiento de clientes.

Considere este diagrama. RTA, RTB y RTC forman un único agrupamiento. RTC es el RR. Para RTC, RTA y RTB son clientes y todo lo demás es un no cliente. Recuerde que el comando neighbor route-reflector-client señala a los clientes de un RR. El mismo RTD es el RR para clientes RTE y RTF. RTG es un RR en un tercer agrupamiento.

Nota: RTD, RTC y RTG están completamente interconectados, pero los routers dentro del agrupamiento no lo están. Cuando un RR recibe una ruta, efectúa el enrutamiento como se muestra en esta lista. Esta actividad depende, sin embargo, del tipo de par:

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

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

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

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

RTC#

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


RTB#

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


RTD#

router bgp 100
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 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 de algunos métodos para evitar este bucle:

  • originator-id: es un atributo BGP opcional, no transitivo, que tiene una longitud de 4 bytes. Un RR crea este atributo. El atributo incorpora el ID del router (RID) del creador de la ruta en el AS local. Si, debido a una configuración mal definida, la información de enrutamiento vuelve al creador, ésta se pasa por alto.

  • cluster-list: la sección Varios RR dentro de un agrupamiento presenta la lista de agrupamientos.

Varios RR dentro de un agrupamiento

bgp-toc32.gif

Generalmente, un agrupamiento de clientes tiene un único RR. En este caso, el ID del router del RR lo identifica. Para aumentar la redundancia y evitar puntos de error, un agrupamiento puede tener más de un RR. Configure todos los RR del mismo agrupamiento con un ID de agrupamiento de 4 bytes de modo que el RR pueda reconocer las actualizaciones en el mismo agrupamiento.

Una lista de agrupamientos es una secuencia de ID de agrupamiento que la ruta ha transferido. Cuando un RR refleja una ruta de clientes RR a no clientes fuera del agrupamiento, el RR agrega el ID del agrupamiento local a la lista de agrupamientos. Si esta actualización tiene una lista de agrupamientos vacía, el RR crea una. Con este atributo, un RR puede identificar si la información de enrutamiento ha creado un bucle al mismo agrupamiento debido a una configuración incorrecta. Si el ID de agrupamiento local se encuentra en la lista de agrupamientos, el anuncio se omite.

En el diagrama de esta sección, RTD, RTE, RTF y RTH pertenecen a un agrupamiento. RTD y RTH son RR para el mismo agrupamiento.

Nota: hay redundancia porque RTH tiene un par completamente interconectado con todos los RR. Si RTD no está activo, RTH toma su lugar.

A continuación se presenta la configuración de RTH, RTD, RTF y RTC:

RTH#

router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100
neighbor 9.9.9.9 remote-as 300
bgp cluster-id 10


RTD#

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


RTF#

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


RTC#

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

Nota: no necesita el comando bgp cluster-id para RTC porque en dicho agrupamiento sólo hay un RR.

Nota importante: esta configuración no usa grupos de pares. No los emplee si los clientes de un agrupamiento no tienen pares iBGP directos entre ellos y los clientes intercambian actualizaciones a través del RR. Si configura grupos de pares, un posible repliegue al origen de una ruta en el RR se transmite a todos los clientes del agrupamiento. Esta transmisión puede producir problemas.

El subcomando bgp client-to-client reflection del router está habilitado de forma predeterminada en el RR. Si desactiva el reflejo cliente a cliente de BGP en el RR y crea pares BGP redundantes entre los clientes, puede usar los grupos de pares de forma segura.

RR e interlocutores BGP convencionales

Un sistema autónomo (AS) puede tener interlocutores BGP que no comprendan el concepto de reflectores de ruta (RR). Este documento llama a estos routers interlocutores BGP convencionales. El esquema de RR permite la coexistencia de dichos interlocutores. Estos routers pueden ser miembros de un grupo de clientes o de un grupo de no clientes. Su existencia permite una migración fácil y gradual del actual modelo iBGP al modelo RR. Puede empezar a crear agrupamiento si configura un único router como RR y hace que otros RR y otros clientes RR normales sean pares iBGP. A continuación, puede crear más agrupamientos gradualmente.

bgp-toc33.gif

En este diagrama, RTD, RTE y RTF tienen el concepto de reflejo de ruta. RTC, RTA y RTB son routers "convencionales". No puede configurarlos como RR. Puede realizar una interconexión normal de iBGP entre estos routers y RTD. Más tarde, cuando esté listo para efectuar una actualización, puede convertir RTC en RR con clientes RTA y RTB. Los clientes no tienen que comprender el esquema de reflejo de ruta, sólo los RR requieren la actualización.

A continuación se presenta la configuración de RTD y RTC:

RTD#

router bgp 100
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 3.3.3.3 remote-as 100
neighbor 2.2.2.2 remote-as 100
neighbor 1.1.1.1 remote-as 100
neighbor 13.13.13.13 remote-as 300


RTC#

router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 2.2.2.2 remote-as 100
neighbor 1.1.1.1 remote-as 100
neighbor 14.14.14.14 remote-as 400

Cuando esté listo para efectuar una actualización de RTC y convertir RTC en RR, suprima la interconexión completa iBGP y haga que RTA y RTB se conviertan en clientes de RTC.

Métodos para evitar el bucle de información de enrutamiento

Hasta el momento, en este documento se han mencionado dos atributos que puede usar para evitar un posible bucle de información: originator-id y cluster-list.

Otra forma de controlar los bucles es añadir más restricciones en la cláusula set de correspondencias de la ruta de salida. Dicha cláusula set no afecta a las rutas que reflejan a los pares iBGP.

También pueden poner más restricciones en nexthop-self, que es una opción de configuración por vecino. Cuando usa nexthop-self en los RR, la cláusula sólo afecta al salto siguiente de las rutas conocidas de eBGP porque el salto siguiente de las rutas reflejadas no se debe cambiar.

Amortiguación de la inestabilidad de las rutas

La versión 11.0 del software Cisco IOS introdujo la amortiguación de rutas, que es un mecanismo para minimizar el impacto que producen ciertas rutas inestables. La amortiguación de rutas reduce también la oscilación en la red. Puede definir criterios para identificar las rutas que se comportan de forma incorrecta. Una ruta que es inestable recibe una penalización de 1000 por cada caso de inestabilidad. Cuando las penalizaciones acumuladas llegan a un "límite de supresión" predefinido, se procede a la supresión del anuncio de ruta. La penalización se reduce exponencialmente en función de un valor de "tiempo de mitad de vida" preconfigurado. Cuando las penalizaciones disminuyen por debajo de un "límite de reutilización" predefinido, se procede a la anulación de la supresión del anuncio de ruta.

La amortiguación de rutas no se aplica a las rutas que son externas a un AS y cuyo conocimiento se ha adquirido mediante iBGP. De esta forma, la amortiguación de rutas impide una penalización más elevada de los pares iBGP para rutas externas al AS.

La penalización se reduce a una frecuencia de 5 segundos. La anulación de la supresión de las rutas se produce con una frecuencia de 10 segundos. El router conserva la información de amortiguación hasta que la penalización es menor que la mitad del "límite de reutilización". En este punto, el router la depura.

Inicialmente, y como valor predeterminado, la amortiguación está desactivada. Si hay necesidad, esta función puede habilitarse en un futuro próximo como valor predeterminado. Los comandos siguientes controlan la amortiguación de rutas:

  • bgp dampening: activa la amortiguación.

  • no bgp dampening: desactiva la amortiguación.

  • bgp dampening half-life-time : cambia el valor de tiempo de mitad de vida.

Un comando que define todos los parámetros al mismo tiempo es:

  • bgp dampening half-life-time reuse suppress maximum-suppress-time

La lista siguiente detalla la sintaxis:

  • half-life-time : el intervalo es 1-45 minutos y el valor predeterminado actual, 15 minutos.

  • reuse-value : el intervalo es 1-20.000 y el valor predeterminado, 750.

  • suppress-value : el intervalo es 1-20.000 y el valor predeterminado, 2000.

  • max-suppress-time : la duración máxima para la supresión de una ruta. El intervalo es de 1-255 minutos y el valor predeterminado es 4 veces el valor de tiempo de mitad de vida.

bgp-toc34.gif

RTB#
hostname RTB

interface Serial0
 ip address 203.250.15.2 255.255.255.252

interface Serial1
 ip address 192.208.10.6 255.255.255.252

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


RTD#
hostname RTD

interface Loopback0
ip address 192.208.10.174 255.255.255.192

interface Serial0/0
 ip address 192.208.10.5 255.255.255.252

router bgp 300
 network 192.208.10.0
 neighbor 192.208.10.6 remote-as 100

La configuración de RTB establece la amortiguación de rutas con parámetros predeterminados. Si suponemos que el enlace de eBGP a RTD es estable, la tabla BGP de RTB aparece como se indica a continuación:

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

   Network          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 a continuación:

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

   Network          Next Hop          Metric LocPrf Weight Path
 h 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ía hay información sobre inestabilidad.

RTB# show ip bgp 192.208.10.0
BGP routing table entry for 192.208.10.0 255.255.255.0, version 25
Paths: (1 available, no best path)
300 (history entry)
    192.208.10.5 from 192.208.10.5 (192.208.10.174)
Origin IGP, metric 0, external
Dampinfo: penalty 910, flapped 1 times in 0:02:03

La ruta ha recibido una penalización por inestabilidad, pero todavía está por debajo del "límite de supresión". El valor predeterminado es 2000. Todavía no se ha suprimido la ruta. Si se hace inestable algunas veces más, verá lo siguiente:

RTB# show ip bgp
BGP table version is 32, local router ID is 203.250.15.2 Status codes:
s suppressed, d damped, h history, * valid, > best, i - internal Origin codes:
i - IGP, e - EGP, ? - incomplete

   Network          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.0
BGP routing table entry for 192.208.10.0 255.255.255.0, version 32
Paths: (1 available, no best path)
300, (suppressed due to dampening)
192.208.10.5 from 192.208.10.5 (192.208.10.174)
      Origin IGP, metric 0, valid, external
Dampinfo: penalty 2615, flapped 3 times in 0:05:18 , reuse in 0:27:00

La ruta se ha amortiguado o suprimido y se volverá a usar cuando la penalización llegue al "valor de reutilización". En este caso, el valor de reutilización es el valor predeterminado 750. La información de amortiguación se depura cuando la penalización es menor que la mitad del límite de reutilización. En este caso, la depuración tiene lugar cuando la penalización es 375 (750/2=375). Los comandos siguientes muestran y borran la información estadística de inestabilidad:

  • show ip bgp flap-statistics: muestra las estadísticas de inestabilidad para todos los trayectos.

  • show ip bgp flap-statistics regexp regular-expression : muestra las estadísticas de inestabilidad para todos los trayectos que se corresponden con la expresión normal.

  • show ip bgp flap-statistics filter-list list : muestra las estadísticas de inestabilidad para todos los trayectos que superan el filtro.

  • show ip bgp flap-statistics A.B.C.D m.m.m.m : muestra las estadísticas de inestabilidad para una única entrada.

  • show ip bgp flap-statistics A.B.C.D m.m.m.m longer-prefix: muestra las estadísticas de inestabilidad para entradas más específicas.

  • show ip bgp neighbor [dampened-routes] | [flap-statistics] : muestra las estadísticas de inestabilidad para todos los trayectos de un vecino.

  • clear ip bgp flap-statistics : borra las estadísticas de inestabilidad para todas las rutas.

  • clear ip bgp flap-statistics regexp regular-expression : borra las estadísticas de inestabilidad para todos los trayectos que se corresponden con la expresión normal.

  • clear ip bgp flap-statistics filter-list list : borra las estadísticas de inestabilidad para todos los trayectos que superan el filtro.

  • clear ip bgp flap-statistics A.B.C.D m.m.m.m : borra las estadísticas de inestabilidad para una única entrada.

  • clear ip bgp A.B.C.D flap-statistics: borra las estadísticas de inestabilidad para todos los trayectos de un vecino.

Selección de un trayecto por parte de BGP

Ahora que ya se ha familiarizado con los atributos y la terminología de BGP, consulte BGP Best Path Selection Algorithm (Algoritmo de selección del mejor trayecto BGP).

Estudios de casos de BGP 5

Ejemplo de diseño práctico

Esta sección contiene un ejemplo de diseño que muestra la configuración y las tablas de enrutamiento como aparecen en realidad en los routers de Cisco.

bgp-toc35.gif

En esta sección se muestra cómo crear esta configuración paso a paso y los problemas que pueden surgir durante el proceso. Cuando tenga un sistema autónomo (AS) que se conecta a dos ISP mediante eBGP, ejecute siempre iBGP dentro del AS para tener un mejor control de las rutas. En este ejemplo, iBGP se ejecuta dentro de AS100 entre RTA y RTB, y OSPF se ejecuta como IGP. Supongamos que se conecta a dos ISP, AS200 y AS300. Esta es la primera ejecución de las configuraciones para todos los routers:

Nota: estas configuraciones no son las definitivas.

RTA#
hostname RTA

ip subnet-zero

interface Loopback0
 ip address 203.250.13.41 255.255.255.0

interface Ethernet0
ip address 203.250.14.1 255.255.255.0

interface Serial0
 ip address 128.213.63.1 255.255.255.252

router ospf 10
 network 203.250.0.0 0.0.255.255 area 0

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

RTF#
hostname RTF

ip subnet-zero

interface Ethernet0
 ip address 203.250.14.2 255.255.255.0

interface Serial1
 ip address 203.250.15.1 255.255.255.252

router ospf 10
 network 203.250.0.0 0.0.255.255 area 0

RTB#
hostname RTB

ip subnet-zero

interface Serial0
 ip address 203.250.15.2 255.255.255.252

interface Serial1
 ip address 192.208.10.6 255.255.255.252

router ospf 10
 network 203.250.0.0 0.0.255.255 area 0

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

RTC#
hostname RTC

ip subnet-zero

interface Loopback0
 ip address 128.213.63.130 255.255.255.192

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

router bgp 200
 network 128.213.0.0
 neighbor 128.213.63.1 remote-as 100
 neighbor 128.213.63.6 remote-as 400

RTD#
hostname RTD

ip subnet-zero

interface Loopback0
ip address 192.208.10.174 255.255.255.192

interface Serial0/0
 ip address 192.208.10.5 255.255.255.252
!
interface Serial0/1
 ip address 192.208.10.2 255.255.255.252

router bgp 300
 network 192.208.10.0
 neighbor 192.208.10.1 remote-as 500
 neighbor 192.208.10.6 remote-as 100

RTE#
hostname RTE

ip subnet-zero

interface Loopback0
ip address 200.200.10.1 255.255.255.0

interface Serial0
 ip address 195.211.10.2 255.255.255.252

interface Serial1
 ip address 128.213.63.6 255.255.255.252
 clockrate 1000000

router bgp 400
 network 200.200.10.0
 neighbor 128.213.63.5 remote-as 200
 neighbor 195.211.10.1 remote-as 500

RTG#
hostname RTG

ip subnet-zero

interface Loopback0
 ip address 195.211.10.174 255.255.255.192

interface Serial0
 ip address 192.208.10.1 255.255.255.252

interface Serial1
 ip address 195.211.10.1 255.255.255.252

router bgp 500
 network 195.211.10.0
 neighbor 192.208.10.2 remote-as 300
 neighbor 195.211.10.2 remote-as 400

Use siempre el comando network o redistribuya entradas estáticas en BGP para anunciar redes. Este método es mejor que redistribuir IGP en BGP. En el ejemplo se usa el comando network para inyectar redes en BGP.

Aquí, se empieza con la interfaz s1 durante el cierre de RTB, como si el enlace entre RTB y RTD no existiera. La tabla BGP de RTB es como se indica a continuación:

RTB# show ip bgp BGP
table version is 4, local router ID is 203.250.15.2 Status
codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
     Network          Next Hop          Metric LocPrf Weight Path
*i128.213.0.0      128.213.63.2           0    100      0 200 i
*i192.208.10.0     128.213.63.2                100      0 200 400 500
300 i
*i195.211.10.0     128.213.63.2                100      0 200 400 500 i
*i200.200.10.0     128.213.63.2                100      0 200 400 i
*>i203.250.13.0    203.250.13.41          0    100      0 i
*>i203.250.14.0    203.250.13.41          0    100      0 i
*>203.250.15.0     0.0.0.0                0         32768 i

En esta tabla, aparecen las anotaciones siguientes:

  • Una i al principio: indica que un par iBGP ha dado a conocer la entrada.

  • Una i al final: indica que el origen de la información de trayecto es IGP.

  • Path: esta información es intuitiva. La red 128.213.0.0, por ejemplo, se ha dado a conocer mediante el trayecto 200 con un salto siguiente de 128.213.63.2.

    Nota: cualquier entrada generada localmente, como 203.250.15.0, tiene un salto siguiente 0.0.0.0.

  • Un >: indica que BGP ha elegido la mejor ruta. BGP usa los pasos de decisión que se detallan en el documento BGP Best Path Selection Algorithm (Algoritmo de selección del mejor trayecto BGP). BGP selecciona el mejor trayecto para llegar a un destino, lo instala en la tabla de enrutamiento de IP y lo anuncia a otros pares BGP.

    Nota: observe el atributo Next Hop. RTB tiene conocimiento de 128.213.0.0 por un salto siguiente de 128.213.63.2, que es el salto siguiente eBGP que se ejecuta en iBGP.

Consulte la tabla de enrutamiento de IP:

RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default

Gateway of last resort is not set

     203.250.13.0 255.255.255.255 is subnetted, 1 subnets
O       203.250.13.41 [110/75] via 203.250.15.1, 02:50:45, Serial0
     203.250.15.0 255.255.255.252 is subnetted, 1 subnets
C       203.250.15.0 is directly connected, Serial0
O    203.250.14.0 [110/74] via 203.250.15.1, 02:50:46, Serial0

Aparentemente, ninguna de las entradas BGP tiene acceso a ella. Hay dos problemas aquí:

El primero es que no se puede acceder al salto siguiente para estas entradas, 128.213.63.2. No hay forma alguna de tener acceso al salto siguiente mediante este IGP, que es OSPF. RTB no ha obtenido conocimiento de 128.213.63.0 mediante OSPF. Puede ejecutar OSPF en la interfaz s0 de RTA y hacerla pasiva; de esta forma, RTB sabe cómo puede tener acceso al salto siguiente 128.213.63.2. Esta configuración de RTA aparece aquí:

RTA#
hostname RTA

ip subnet-zero

interface Loopback0
 ip address 203.250.13.41 255.255.255.0

interface Ethernet0
ip address 203.250.14.1 255.255.255.0

interface Serial0
 ip address 128.213.63.1 255.255.255.252

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

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

Nota: puede ejecutar el comando bgp nexthopself entre RTA y RTB para cambiar el salto siguiente.

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

RTB# show ip bgp
BGP table version is 10, local router ID is 203.250.15.2
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop          Metric LocPrf Weight Path
*>i128.213.0.0      128.213.63.2           0    100      0 200 i
*>i192.208.10.0     128.213.63.2                100      0 200 400 500
300 i
*>i195.211.10.0     128.213.63.2                100      0 200 400 500 i
*>i200.200.10.0     128.213.63.2                100      0 200 400 i
*>i203.250.13.0     203.250.13.41          0    100      0 i
*>i203.250.14.0     203.250.13.41          0    100      0 i
*> 203.250.15.0     0.0.0.0                0         32768 i

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

Consulte la tabla de enrutamiento:

RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is not set

     203.250.13.0 255.255.255.255 is subnetted, 1 subnets
O       203.250.13.41 [110/75] via 203.250.15.1, 00:04:46, Serial0
     203.250.15.0 255.255.255.252 is subnetted, 1 subnets
C       203.250.15.0 is directly connected, Serial0
O    203.250.14.0 [110/74] via 203.250.15.1, 00:04:46, Serial0
     128.213.0.0 255.255.255.252 is subnetted, 1 subnets
O       128.213.63.0 [110/138] via 203.250.15.1, 00:04:47, Serial0

El segundo problema es que todavía no se ven las entradas BGP en la tabla de enrutamiento. La única diferencia es que ahora puede tener acceso a 128.213.63.0 a través de OSPF. Se trata de un problema de sincronización. BGP no incorpora estas entradas en la tabla de enrutamiento y no las envía en las actualizaciones de BGP por falta de sincronización con IGP.

Nota: RTF no tiene conocimiento de las redes 192.208.10.0 y 195.211.10.0 porque todavía no ha redistribuido BGP en OSPF.

En este escenario, si desactiva la sincronización, las entradas aparecen en la tabla de enrutamiento. Pero aún no hay conectividad.

Si desactiva la sincronización en RTB, ocurre lo siguiente:

RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is not set

B    200.200.10.0 [200/0] via 128.213.63.2, 00:01:07
B    195.211.10.0 [200/0] via 128.213.63.2, 00:01:07
B    192.208.10.0 [200/0] via 128.213.63.2, 00:01:07
     203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O       203.250.13.41 255.255.255.255
           [110/75] via 203.250.15.1, 00:12:37, Serial0
B       203.250.13.0 255.255.255.0 [200/0] via 203.250.13.41, 00:01:08
     203.250.15.0 255.255.255.252 is subnetted, 1 subnets
C       203.250.15.0 is directly connected, Serial0
O    203.250.14.0 [110/74] via 203.250.15.1, 00:12:37, Serial0
     128.213.0.0 is variably subnetted, 2 subnets, 2 masks
B       128.213.0.0 255.255.0.0 [200/0] via 128.213.63.2, 00:01:08
O       128.213.63.0 255.255.255.252
           [110/138] via 203.250.15.1, 00:12:37, Serial0

La tabla de enrutamiento parece correcta, pero no hay forma alguna de tener acceso a esas redes. RTF, situado en medio, no sabe cómo obtener acceso a ellas:

RTF# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is not set

     203.250.13.0 255.255.255.255 is subnetted, 1 subnets
O       203.250.13.41 [110/11] via 203.250.14.1, 00:14:15, Ethernet0
     203.250.15.0 255.255.255.252 is subnetted, 1 subnets
C       203.250.15.0 is directly connected, Serial1
C    203.250.14.0 is directly connected, Ethernet0
     128.213.0.0 255.255.255.252 is subnetted, 1 subnets
O       128.213.63.0 [110/74] via 203.250.14.1, 00:14:15, Ethernet0

Cuando se desactiva la sincronización en esta situación, el problema todavía existe. Sin embargo, la sincronización se necesitará más adelante para otros temas. Redistribuya BGP en OSPF en RTA, con una métrica de 2000:

RTA#
hostname RTA

ip subnet-zero

interface Loopback0
 ip address 203.250.13.41 255.255.255.0

interface Ethernet0
ip address 203.250.14.1 255.255.255.0

interface Serial0
 ip address 128.213.63.1 255.255.255.252

router ospf 10
 redistribute bgp 100 metric 2000 subnets
 passive-interface Serial0
 network 203.250.0.0 0.0.255.255 area 0
 network 128.213.0.0 0.0.255.255 area 0

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

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

RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is not set

O E2 200.200.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
O E2 195.211.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
O E2 192.208.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
     203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O       203.250.13.41 255.255.255.255
           [110/75] via 203.250.15.1, 00:00:15, Serial0
O E2    203.250.13.0 255.255.255.0
           [110/2000] via 203.250.15.1, 00:00:15, Serial0
     203.250.15.0 255.255.255.252 is subnetted, 2 subnets
C       203.250.15.8 is directly connected, Loopback1
C       203.250.15.0 is directly connected, Serial0
O    203.250.14.0 [110/74] via 203.250.15.1, 00:00:15, Serial0
     128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2    128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1,
00:00:15,Serial0
O       128.213.63.0 255.255.255.252
           [110/138] via 203.250.15.1, 00:00:16, Serial0

Las entradas BGP han desaparecido porque OSPF tiene una distancia mejor que iBGP. La distancia OSPF es 110, mientras que la distancia iBGP es 200.

Desactive la sincronización en RTA de modo que pueda anunciar 203.250.15.0. Esta acción es necesaria porque RTA no sincroniza con OSPF debido a la diferencia en máscaras. Mantenga la sincronización desactivada en RTB de modo que pueda anunciar 203.250.13.0. Esta acción es necesaria en RTB por el mismo motivo.

Observemos ahora la interfaz s1 de RTB para ver cómo son las rutas. Habilite también OSPF en serie 1 de RTB para hacerlo pasivo. Este paso permite a RTA tener conocimiento del salto siguiente 192.208.10.5 a través de IGP. Si lo omite, pueden producirse bucles de enrutamiento porque para tener acceso al salto siguiente 192.208.10.5, debe ir por el otro camino a través de eBGP. A continuación se indican las nuevas configuraciones de RTA y RTB:

RTA#
hostname RTA

ip subnet-zero

interface Loopback0
 ip address 203.250.13.41 255.255.255.0

interface Ethernet0
ip address 203.250.14.1 255.255.255.0

interface Serial0
 ip address 128.213.63.1 255.255.255.252

router ospf 10
 redistribute bgp 100 metric 2000 subnets
 passive-interface Serial0
 network 203.250.0.0 0.0.255.255 area 0
 network 128.213.0.0 0.0.255.255 area 0

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

RTB#
hostname RTB

ip subnet-zero

interface Serial0
 ip address 203.250.15.2 255.255.255.252

interface Serial1
 ip address 192.208.10.6 255.255.255.252

router ospf 10
 redistribute bgp 100 metric 1000 subnets
 passive-interface Serial1
 network 203.250.0.0 0.0.255.255 area 0
 network 192.208.0.0 0.0.255.255 area 0

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

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

RTA# show ip bgp
BGP table version is 117, local router ID is 203.250.13.41
Status codes: s suppressed, d damped, h history, * valid, > best,
i -internal Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          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 bgp
BGP table version is 12, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best,
i -internal Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          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 400
200 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 un ISP de respaldo. Puede tener conocimiento de rutas parciales por uno de los ISP y asignar rutas predeterminadas a ambos. En este ejemplo, recibe rutas parciales de AS200 y sólo rutas locales de AS300. RTA y RTB generan rutas predeterminadas en OSPF, con RTB como preferencia debido a la métrica más baja. De esta forma, puede equilibrar el tráfico de salida entre los dos ISP.

Es posible que surja una asimetría si el tráfico que deja RTA vuelve por RTB. Esta situación puede ocurrir si usa el mismo agrupamiento de direcciones IP, la misma red principal, cuando se comunica con los dos ISP. Debido a la agrupación, el mundo exterior verá el AS como una entidad global. Los puntos de entrada a la red pueden tener lugar por RTA o RTB. Puede descubrir que todo el tráfico de entrada al AS llega por un único punto, aunque disponga de múltiples puntos en Internet. En este ejemplo, tiene dos redes principales importantes cuando se comunica con los dos ISP.

Otro motivo potencial para la asimetría es la diferencia en la longitud del trayecto anunciado para tener acceso al AS. Puede que un proveedor de servicios esté más cercano a un determinado destino que otro. En este ejemplo, el tráfico de AS400 que tiene la red como destino siempre se transfiere por RTA debido a que su trayecto es más corto. Puede intentar llevar a cabo dicha decisión. Utilice el comando set as-path prepend para agregar números de trayecto a las actualizaciones y hacer que la longitud parezca más larga. Sin embargo, con atributos como preferencia local, métrica o peso, AS400 puede haber establecido el punto de salida en AS200. En este caso, no hay nada que se pueda hacer.

Esta configuración es la configuración final para todos los routers:

RTA#
hostname RTA

ip subnet-zero

interface Loopback0
 ip address 203.250.13.41 255.255.255.0

interface Ethernet0
 ip address 203.250.14.1 255.255.255.0

interface Serial0
 ip address 128.213.63.1 255.255.255.252

router ospf 10
 redistribute bgp 100 metric 2000 subnets
 passive-interface Serial0
 network 203.250.0.0 0.0.255.255 area 0
 network 128.213.0.0 0.0.255.255 area 0
 default-information originate metric 2000

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

ip classless
ip default-network 200.200.0.0

route-map setlocalpref permit 10
 set local-preference 200

En RTA, la preferencia local para las rutas que proceden de AS200 se establece en 200. Además, la red 200.200.0.0 es la opción elegida como candidata predeterminada. El comando ip default-network permite elegir el valor predeterminado.

Asimismo, en este ejemplo, el uso del comando default-information originate con OSPF inyecta la ruta predeterminada dentro del dominio OSPF. Este ejemplo también emplea este comando con el protocolo Sistema intermedio a sistema intermedio (Protocolo IS-IS) y BGP. Para RIP, hay una redistribución automática en RIP de 0.0.0.0, sin configuración adicional. Para IGRP y EIGRP, la inyección de la información predeterminada en el dominio de IGP tiene lugar tras la redistribución de BGP en IGRP y EIGRP. Con IGRP y EIGRP, también puede redistribuir una ruta estática de 0.0.0.0 en el ámbito de IGP.

RTF#
hostname RTF

ip subnet-zero

interface Ethernet0
 ip address 203.250.14.2 255.255.255.0

interface Serial1
 ip address 203.250.15.1 255.255.255.252

router ospf 10
 network 203.250.0.0 0.0.255.255 area 0

ip classless

RTB#
hostname RTB

ip subnet-zero

interface Loopback1
 ip address 203.250.15.10 255.255.255.252

interface Serial0
 ip address 203.250.15.2 255.255.255.252
!
interface Serial1
 ip address 192.208.10.6 255.255.255.252

router ospf 10
 redistribute bgp 100 metric 1000 subnets
 passive-interface Serial1
 network 203.250.0.0 0.0.255.255 area 0
 network 192.208.10.6 0.0.0.0 area 0
 default-information originate metric 1000
!
router bgp 100
 no synchronization
 network 203.250.15.0
 neighbor 192.208.10.5 remote-as 300
 neighbor 192.208.10.5 route-map localonly in
 neighbor 203.250.13.41 remote-as 100
!
ip classless
ip default-network 192.208.10.0
ip as-path access-list 1 permit ^300$

route-map localonly permit 10
 match as-path 1
set local-preference 300

Para RTB, la preferencia local de las actualizaciones que proceden de AS300 se establece en 300. Este valor es superior al valor de preferencia local de las actualizaciones de iBGP que proceden de RTA. De esta forma, AS100 selecciona RTB para las rutas locales de AS300. Cualquier otra ruta de RTB, si la hay, se transmite internamente con una preferencia local de 100. Este valor es inferior a la preferencia local de 200, que procede de RTA; por lo que RTA es la preferencia.

Nota: sólo se anuncian las rutas locales de AS300. Toda información de trayecto que no coincida con ^300$ se descarta. Si desea anunciar las rutas locales y las rutas vecinas, que son los clientes de ISP, use ^300_[0-9]*.

A continuación se proporciona en el resultado de la expresión normal que indica las rutas locales de AS300:

RTB# show ip bgp regexp ^300$
BGP table version is 14, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete

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

RTC#
hostname RTC

ip subnet-zero

interface Loopback0
 ip address 128.213.63.130 255.255.255.192

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

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

ip classless
access-list 1 deny   195.211.0.0 0.0.255.255
access-list 1 permit any

En RTC, se agrega 128.213.0.0/16 y se indican las rutas específicas para inyección en AS100. Si el ISP se niega a efectuar esta tarea, se deberá filtrar el extremo de entrada de AS100.

RTD#
hostname RTD

ip subnet-zero

interface Loopback0
 ip address 192.208.10.174 255.255.255.192
!
interface Serial0/0
 ip address 192.208.10.5 255.255.255.252
!
interface Serial0/1
 ip address 192.208.10.2 255.255.255.252

router bgp 300
 network 192.208.10.0
 neighbor 192.208.10.1 remote-as 500
 neighbor 192.208.10.6 remote-as 100

RTG#
hostname RTG

ip subnet-zero

interface Loopback0
 ip address 195.211.10.174 255.255.255.192

interface Serial0
 ip address 192.208.10.1 255.255.255.252

interface Serial1
 ip address 195.211.10.1 255.255.255.252

router bgp 500
 network 195.211.10.0
 aggregate-address 195.211.0.0 255.255.0.0 summary-only
 neighbor 192.208.10.2 remote-as 300
 neighbor 192.208.10.2 send-community
 neighbor 192.208.10.2 route-map setcommunity out
 neighbor 195.211.10.2 remote-as 400
!
ip classless
access-list 1 permit 195.211.0.0 0.0.255.255
access-list 2 permit any
route-map setcommunity permit 20
 match ip address 2
!
route-map setcommunity permit 10
 match ip address 1
 set community no-export

En RTG se encuentra la demostración del uso de los filtros de la comunidad. Se agrega una comunidad no-export a las actualizaciones de 195.211.0.0 hacia RTD. De esta forma, RTD no exporta dicha ruta a RTB. En este caso, sin embargo, RTB tampoco acepta estas rutas.

RTE#
hostname RTE

ip subnet-zero

interface Loopback0
 ip address 200.200.10.1 255.255.255.0

interface Serial0
 ip address 195.211.10.2 255.255.255.252

interface Serial1
 ip address 128.213.63.6 255.255.255.252

router bgp 400
 network 200.200.10.0
 aggregate-address 200.200.0.0 255.255.0.0 summary-only
 neighbor 128.213.63.5 remote-as 200
 neighbor 195.211.10.1 remote-as 500

ip classless

RTE agrega 200.200.0.0/16. Aquí se presentan las tablas finales de enrutamiento y BGP para RTA, RTF y RTB:

RTA# show ip bgp
BGP table version is 21, local router ID is 203.250.13.41
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          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 route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is 128.213.63.2 to network 200.200.0.0

     192.208.10.0 is variably subnetted, 2 subnets, 2 masks
O E2    192.208.10.0 255.255.255.0
           [110/1000] via 203.250.14.2, 00:41:25, Ethernet0
O       192.208.10.4 255.255.255.252
           [110/138] via 203.250.14.2, 00:41:25, Ethernet0
C    203.250.13.0 is directly connected, Loopback0
     203.250.15.0 is variably subnetted, 3 subnets, 3 masks
O       203.250.15.10 255.255.255.255
           [110/75] via 203.250.14.2, 00:41:25, Ethernet0
O       203.250.15.0 255.255.255.252
           [110/74] via 203.250.14.2, 00:41:25, Ethernet0
B       203.250.15.0 255.255.255.0 [200/0] via 203.250.15.2, 00:41:25
C    203.250.14.0 is directly connected, Ethernet0
     128.213.0.0 is variably subnetted, 2 subnets, 2 masks
B       128.213.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:41:26
C       128.213.63.0 255.255.255.252 is directly connected, Serial0
O*E2 0.0.0.0/0 [110/1000] via 203.250.14.2, Ethernet0/0
B*   200.200.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:02:38

RTF# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is 203.250.15.2 to network 0.0.0.0

     192.208.10.0 is variably subnetted, 2 subnets, 2 masks
O E2    192.208.10.0 255.255.255.0
           [110/1000] via 203.250.15.2, 00:48:50, Serial1
O       192.208.10.4 255.255.255.252
           [110/128] via 203.250.15.2, 01:12:09, Serial1
     203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O       203.250.13.41 255.255.255.255
           [110/11] via 203.250.14.1, 01:12:09, Ethernet0
O E2    203.250.13.0 255.255.255.0
           [110/2000] via 203.250.14.1, 01:12:09, Ethernet0
     203.250.15.0 is variably subnetted, 2 subnets, 2 masks
O       203.250.15.10 255.255.255.255
           [110/65] via 203.250.15.2, 01:12:09, Serial1
C       203.250.15.0 255.255.255.252 is directly connected, Serial1
C    203.250.14.0 is directly connected, Ethernet0
     128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2    128.213.0.0 255.255.0.0
           [110/2000] via 203.250.14.1, 00:45:01, Ethernet0
O       128.213.63.0 255.255.255.252
           [110/74] via 203.250.14.1, 01:12:11, Ethernet0
O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.14.1, 00:03:47,
Ethernet0
O*E2 0.0.0.0 0.0.0.0 [110/1000] via 203.250.15.2, 00:03:33, Serial1

Nota: la tabla de enrutamiento RTF indica que la forma de tener acceso a redes locales de AS300, como 192.208.10.0, es a través de RTB. La forma de poder conectarse a otras redes conocidas, como 200.200.0.0, es a través de RTA. La gateway del último recurso se establece en RTB. Si hay algún problema con la conexión entre RTB y RTD, el valor predeterminado que RTA anuncia se inicia con una métrica de 2000.

RTB# show ip bgp
BGP table version is 14, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          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

RTB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * -
candidate default

Gateway of last resort is 192.208.10.5 to network 192.208.10.0

 *   192.208.10.0 is variably subnetted, 2 subnets, 2 masks
B*      192.208.10.0 255.255.255.0 [20/0] via 192.208.10.5, 00:50:46
C       192.208.10.4 255.255.255.252 is directly connected, Serial1
     203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O       203.250.13.41 255.255.255.255
           [110/75] via 203.250.15.1, 01:20:33, Serial0
O E2    203.250.13.0 255.255.255.0
           [110/2000] via 203.250.15.1, 01:15:40, Serial0
     203.250.15.0 255.255.255.252 is subnetted, 2 subnets
C       203.250.15.8 is directly connected, Loopback1
C       203.250.15.0 is directly connected, Serial0
O    203.250.14.0 [110/74] via 203.250.15.1, 01:20:33, Serial0
     128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2    128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:46:55, Serial0
O       128.213.63.0 255.255.255.252
           [110/138] via 203.250.15.1, 01:20:34, Serial0
O*E2 0.0.0.0/0 [110/2000] via 203.250.15.1, 00:08:33, Serial0
O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:05:42, Serial0

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 26634