Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

Descripción General del Atributo de Métrica AIGP

Cambios en el Algoritmo de Selección de la Mejor Trayectoria de BGP

Consideraciones importantes

Solución para routers heredados

Configurar

Habilitar la transmisión del atributo AIGP

Origine el AIGP

Botón para desactivar la interrupción del tiempo de AIGP

Solución para routers heredados

Traducción de AIGP a Comunidad de Costes

Traducción del AIGP al MED

Verificación

Troubleshoot

Introducción

Este documento describe cómo configurar el atributo métrico del protocolo de gateway interior acumulado (AIGP) que se transporta mediante el protocolo de gateway fronterizo (BGP) en Cisco IOS®.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Antecedentes

Esta sección proporciona una descripción general del atributo métrico AIGP y algunas consideraciones importantes con respecto a su uso.

Descripción General del Atributo de Métrica AIGP

Es posible que las empresas deseen implementar un diseño de red en el que la red esté dividida con varios protocolos de gateway interior (IGP), cada uno con un sistema autónomo BGP. Esto se utiliza por razones de escalabilidad, donde la red se vuelve demasiado grande para un IGP. El BGP ayuda a escalar cuando transporta algunas de las rutas que de otra manera serían transportadas por el IGP. La solución que utiliza AIGP está pensada para redes con diferentes sistemas autónomos BGP bajo un control administrativo.

Aquí tiene un ejemplo:

El servicio de extremo a extremo es una VPN de switching de etiquetas multiprotocolo (MPLS). Cuando hay un gran número de routers de borde del proveedor (PE) en la red, el IGP debe transportar demasiadas rutas. La solución es hacer que BGP lleve las interfaces de loopback de los routers PE. La solución que se utiliza para asegurarse de que el trayecto conmutado de etiquetas MPLS (LSP) no se interrumpa de extremo a extremo es utilizar la etiqueta BGP IPv4 +. Esto significa que RFC 3107 se utiliza entre los routers PE y los routers de borde, que conectan los diferentes dominios IGP.

El problema con esta solución es que los routers de borde o los routers PE ya no pueden tomar una decisión sobre la mejor trayectoria, basada en la métrica más corta de extremo a extremo, porque ya no hay un IGP que se ejecute en toda la red. La solución a este problema es el nuevo atributo BGP, denominado Atributo de Métrica IGP Acumulado o atributo de métrica AIGP. Este atributo BGP no transitivo transporta la métrica acumulada para las trayectorias de modo que los altavoces BGP reciban conocimiento de la métrica de extremo a extremo para esas trayectorias.

Los altavoces BGP deben agregar la ruta a la métrica de salto siguiente al valor actual en el atributo de métrica AIGP antes de reenviar la ruta.

Nota: La comparación de las trayectorias para una ruta se realiza inmediatamente después de la comparación de la preferencia local. Refiérase al documento Algoritmo de Selección de Mejor Trayectoria de BGP Cisco para obtener más detalles sobre el Algoritmo de Selección de Mejor Trayectoria de BGP.

Esta solución es similar a la solución en la que se establece el Multi Exit Discriminator (MED) en la métrica IGP. Sin embargo, en este caso, el paso 6 (el MED más bajo) decide la mejor trayectoria. Este paso viene después del paso 4, donde la trayectoria más corta decide la mejor trayectoria. La mejor trayectoria se encuentra a menudo antes de que se alcance el paso 6. Con la solución AIGP, la decisión BGP normal se cambia de modo que el AIGP se verifique después del paso 3 para determinar si la ruta se anunció localmente. Si diferentes sistemas autónomos vecinos (AS) coinciden con el altavoz BGP, significa que el valor always-compare-med debe estar habilitado.

El atributo de métrica AIGP se especifica en RFC 7311, que es el Atributo de Métrica IGP Acumulado para BGP. Para transportar el valor de métrica AIGP en la comunidad de costes, se utilizan los procedimientos especificados en draft-retana-idr-aigp-cost-community (Uso de la Comunidad de Costes para transportar la métrica IGP acumulada).

Nota: La métrica AIGP BGP atribuida proporciona un ruteo óptimo en las redes donde se interconectan diferentes dominios de ruteo a través del BGP.

Cambios en el Algoritmo de Selección de la Mejor Trayectoria de BGP

Cuando se utiliza AIGP, se realizan estos cambios en el Algoritmo de Selección de la Mejor Trayectoria de BGP:

- El Algoritmo de Selección de la Mejor Trayectoria de BGP se modifica para comparar el AIGP inmediatamente después del paso 3 (Rutas anunciadas localmente) y después de la verificación del salto siguiente es válido.

- Cuando el router considera una trayectoria AIGP contra una trayectoria AIGP, el valor de la métrica AIGP se agrega a la métrica hacia el salto siguiente.

- Cuando el router considera una trayectoria AIGP frente a una trayectoria que no es AIGP, el BGP prefiere la trayectoria con el atributo AIGP de forma predeterminada.

- Cuando se compara la métrica IGP más baja con el salto siguiente BGP, se toma en cuenta el costo AIGP.

- Si la ruta hacia el salto siguiente tiene una métrica AIGP, la métrica se agrega a la métrica IGP hacia el salto siguiente. Esta suma es la nueva métrica IGP (costo interior) para la ruta. Esto ocurre cuando una ruta BGP es recursiva a otra ruta BGP.

Consideraciones importantes

Si los IGP de la red son de diferentes tipos (Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP)), es poco probable que la métrica resultante del uso del atributo AIGP genere resultados coherentes o razonables. Si se utiliza el mismo IGP en los diferentes dominios, se debe utilizar la misma configuración de métrica para garantizar resultados consistentes.

Para que los routers de borde o los routers PE tengan la capacidad de decidir entre trayectos múltiples (según la métrica derivada de AIGP) primero deben recibir trayectos múltiples. Por esta razón, es posible que se le pida que habilite la función BGP ruta adicional (ADD-Path) o anunciar mejor externa.

Los peers BGP que se habilitan para AIGP y los que no se colocan en grupos de actualización separados. Además, los peers BGP que se habilitan para AIGP en la comunidad de costos se colocan en grupos de actualización independientes.

Solución para routers heredados

Si hay routers en la red que no son capaces de AIGP (routers heredados), hay dos soluciones posibles:

- Un router puede traducir el AIGP a una comunidad de costos, asociarlo a la ruta y anunciar la ruta al router heredado.

- Un router puede traducir el AIGP al MED, conectarlo a la ruta y anunciar la ruta al router heredado.

Configurar

Esta sección describe cómo configurar el atributo de métrica AIGP.

Habilitar la transmisión del atributo AIGP

El AIGP se debe habilitar explícitamente para las sesiones BGP interno (iBGP) y BGP externo (eBGP) con el neighbor ip-address aigp comando.

Así se verifica si el AIGP está habilitado para el peer BGP:

P3#show bgp ipv4 unicast neighbors 10.1.9.2 | in AIGP

For address family: IPv4 Unicast

AIGP is enabled

Origine el AIGP

El AIGP se puede establecer en la métrica IGP o en un valor. Además, el AIGP se puede configurar para algunas rutas específicas solamente para un IGP a través de un route-map. Cuando el originador del AIGP ve un cambio en la métrica IGP, debe enviar una nueva actualización BGP con los nuevos valores AIGP para las rutas afectadas.

La métrica AIGP se puede establecer automáticamente en la métrica IGP o en algún valor arbitrario de 32 bits:

P1(config-route-map)#set aigp-metric ?

<0-4294967295>  manual value

igp-metric      metric value from rib

Este ejemplo muestra cómo establecer la métrica AIGP en la métrica de la ruta IGP:

ip prefix-list loopback seq 5 permit 10.100.1.1/32

!

route-map redistribute-loopback permit 10

match ip address prefix-list loopback

set aigp-metric igp-metric

Botón para desactivar la interrupción del tiempo de AIGP

Si se habilita este botón, el BGP no utiliza el desempate AIGP a menos que ambas trayectorias tengan el atributo métrico AIGP. Esto significa que el atributo AIGP no se evalúa durante el proceso de selección de la mejor trayectoria entre dos trayectos cuando una trayectoria no tiene el atributo AIGP.

Aquí tiene un ejemplo:

router bgp 65000

bgp bestpath aigp ignore

Solución para routers heredados

Si el router PE2 no tiene software que admita el atributo métrico AIGP (es un router heredado), entonces hay dos soluciones que puede utilizar.

Traducción de AIGP a Comunidad de Costes

Configure los routers P3 y P4 para traducir el costo IGP a una comunidad de costos que el router pueda anunciar a un router heredado:

P3#show run | beg router bgp

router bgp 65000

address-family ipv4

neighbor 10.1.9.2 activate

neighbor 10.1.9.2 send-community both

neighbor 10.1.9.2 aigp send cost-community 100 poi igp-cost transitive

P4#show run | beg router bgp

router bgp 65000

address-family ipv4

neighbor 10.1.10.2 activate

neighbor 10.1.10.2 send-community both

neighbor 10.1.10.2 aigp send cost-community 100 poi igp-cost transitive

Debe permitir que el router que envía envíe comunidades extendidas. Esto significa que debe especificar el send-community extended or send-community both atributos(neighbor x.x.x.x send-community) para el par BGP.

Aquí tiene un ejemplo:

PE2#show bgp ipv4 unicast 10.100.1.1

BGP routing table entry for 10.100.1.1/32, version 6

Paths: (2 available, best #1, table default)

Advertised to update-groups:

6

Refresh Epoch 2

65000 65001

10.1.9.4 from 10.1.9.4 (10.100.1.4)

Origin incomplete, localpref 100, valid, external, best

Extended Community: Cost(transitive):igp:100:6

mpls labels in/out 17/16

rx pathid: 0, tx pathid: 0x0

Refresh Epoch 15

65000 65001

10.1.10.6 from 10.1.10.6 (10.100.1.6)

Origin incomplete, localpref 100, valid, external

Extended Community: Cost(transitive):igp:100:11

mpls labels in/out 17/30

rx pathid: 0, tx pathid: 0

Como se muestra, el router PE2 eligió la trayectoria con el costo más bajo (100:6 versus 100:11) como la mejor trayectoria.

Traducción del AIGP al MED

Configure los routers P3 y P4 para traducir el costo IGP al MED que el router puede anunciar a un router heredado.

Esta es la configuración en el router P3:

router bgp 65000

address-family ipv4

neighbor 10.1.9.2 activate

neighbor 10.1.9.2 send-community both

neighbor 10.1.9.2 aigp send med

Esta es la configuración en el router P4:

router bgp 65000

address-family ipv4

neighbor 10.1.10.2 activate

neighbor 10.1.10.2 send-community both

neighbor 10.1.10.2 aigp send med

Verificación

El resultado del debug bgp ipv4 unicast updates in muestra el uso del atributo métrico AIGP:

PE2#

BGP(0): 10.1.9.4 rcvd UPDATE w/ attr: nexthop 10.1.9.4, origin ?, aigp-metric 22,

merged path 65000 65001, AS_PATH

Cuando ve la imagen proporcionada en la sección de este documento, puede ver que todos los links en la red AS 6500 tienen un costo OSPF de 10, los links entre los routers P1 y P4 y entre P2 y P3 tienen un costo OSPF de 100, y el link entre los routers P3 y P1 tiene un costo de 5.

Esta es la ruta para 10.100.1.1/32, como se ve en el router P3:

P3#show bgp ipv4 unicast 10.100.1.1

BGP routing table entry for 10.100.1.1/32, version 9

Paths: (2 available, best #1, table default)

Additional-path-install

Path advertised to update-groups:

5

Refresh Epoch 5

65001

10.100.1.3 (metric 6) from 10.100.1.7 (10.100.1.7)

Origin incomplete, metric 0, localpref 100, valid, internal, best

Originator: 10.100.1.3, Cluster list: 10.100.1.7

mpls labels in/out 29/16

rx pathid: 0x0, tx pathid: 0x0

Path not advertised to any peer

Refresh Epoch 5

65001

10.100.1.5 (metric 21) from 10.100.1.7 (10.100.1.7)

Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair, all

Originator: 10.100.1.5, Cluster list: 10.100.1.7

mpls labels in/out 29/16

rx pathid: 0x1, tx pathid: 0x1

Esta es la ruta para 10.100.1.1/32, como se ve en el router P4:

P4#show bgp ipv4 unicast 10.100.1.1

BGP routing table entry for 10.100.1.1/32, version 9

Paths: (2 available, best #2, table default)

Additional-path-install

Path not advertised to any peer

Refresh Epoch 5

65001

10.100.1.3 (metric 16) from 10.100.1.7 (10.100.1.7)

Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair, all

Originator: 10.100.1.3, Cluster list: 10.100.1.7

mpls labels in/out 29/16

rx pathid: 0x0, tx pathid: 0x1

Path advertised to update-groups:

35

Refresh Epoch 5

65001

10.100.1.5 (metric 11) from 10.100.1.7 (10.100.1.7)

Origin incomplete, metric 0, localpref 100, valid, internal, best

Originator: 10.100.1.5, Cluster list: 10.100.1.7

mpls labels in/out 29/16

rx pathid: 0x1, tx pathid: 0x0

Esta es la ruta para 10.100.1.1/32, como se ve en el router PE2:

PE2#show bgp ipv4 unicast 10.100.1.1

BGP routing table entry for 10.100.1.1/32, version 4

Paths: (2 available, best #2, table default)

Advertised to update-groups:

5

Refresh Epoch 1

65000 65001

10.1.9.4 from 10.1.9.4 (10.100.1.4)

Origin incomplete, localpref 100, valid, external

mpls labels in/out 18/17

rx pathid: 0, tx pathid: 0

Refresh Epoch 1

65000 65001

10.1.10.6 from 10.1.10.6 (10.100.1.6)

Origin incomplete, localpref 100, valid, external, best

mpls labels in/out 18/30

rx pathid: 0, tx pathid: 0x0

La mejor trayectoria en el router P3 es la trayectoria con la métrica IGP 6, con el router P1 como salto siguiente. La mejor trayectoria en el router P4 es la trayectoria con la métrica IGP 11, con el router P2 como salto siguiente. Los routers P3 y P4 envían su mejor trayectoria hacia el router PE2. El router PE2 elige la trayectoria del router P4 como la mejor, que se decidió porque ambas trayectorias BGP en el router PE2 son muy similares y el paso 10 fue el desempate: se ganó la ruta externa más antigua. Esto significa que el tráfico del router PE2 al router PE1 toma la trayectoria PE2-P4-P2-PE1. Sin embargo, la trayectoria general más corta, cuando se considera el costo IGP, es PE2-P3-P1-PE1.

Utilice la siguiente información para verificar el atributo de métrica AIGP en los routers P3 y P4 hacia el router PE2 (10.100.1.7):

Este es el resultado para el router P3:

router bgp 65000

address-family ipv4

bgp additional-paths select all

bgp additional-paths receive

bgp additional-paths install

neighbor 10.1.9.2 activate

neighbor 10.1.9.2 aigp

neighbor 10.1.9.2 send-label

neighbor 10.100.1.7 activate

neighbor 10.100.1.7 aigp

neighbor 10.100.1.7 next-hop-self

neighbor 10.100.1.7 send-label

Este es el resultado para el router P4:

router bgp 65000

address-family ipv4

bgp additional-paths select all

bgp additional-paths receive

bgp additional-paths install

neighbor 10.1.10.2 activate

neighbor 10.1.10.2 aigp

neighbor 10.1.10.2 send-label

neighbor 10.100.1.7 activate

neighbor 10.100.1.7 aigp

neighbor 10.100.1.7 next-hop-self

neighbor 10.100.1.7 send-label

Puede ver que el router P3 ahora tiene:

P3#show bgp ipv4 unicast 10.100.1.1

BGP routing table entry for 10.100.1.1/32, version 30

Paths: (2 available, best #2, table default)

Additional-path-install

Path not advertised to any peer

Refresh Epoch 11

65001

10.100.1.5 (metric 21) from 10.100.1.7 (10.100.1.7)

Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal,

backup/repair, all

Originator: 10.100.1.5, Cluster list: 10.100.1.7

mpls labels in/out 28/31

rx pathid: 0x1, tx pathid: 0x1

Path advertised to update-groups:

5

Refresh Epoch 11

65001

10.100.1.3 (metric 6) from 10.100.1.7 (10.100.1.7)

Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal, best

Originator: 10.100.1.3, Cluster list: 10.100.1.7

mpls labels in/out 28/30

rx pathid: 0x0, tx pathid: 0x0

El router P4 ahora tiene:

P4#show bgp ipv4 unicast 10.100.1.1

BGP routing table entry for 10.100.1.1/32, version 30

Paths: (2 available, best #1, table default)

Additional-path-install

Path advertised to update-groups:

35

Refresh Epoch 11

65001

10.100.1.5 (metric 11) from 10.100.1.7 (10.100.1.7)

Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal, best

Originator: 10.100.1.5, Cluster list: 10.100.1.7

mpls labels in/out 16/31

rx pathid: 0x1, tx pathid: 0x0

Path not advertised to any peer

Refresh Epoch 11

65001

10.100.1.3 (metric 16) from 10.100.1.7 (10.100.1.7)

Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal,

backup/repair, all

Originator: 10.100.1.3, Cluster list: 10.100.1.7

mpls labels in/out 16/30

rx pathid: 0x0, tx pathid: 0x1

La métrica IGP para las trayectorias en los routers P3 y P4 no cambió, pero el router PE2 ahora recibe las rutas con el atributo AIGP de los routers P3 y P4.

El router PE2 ve las dos trayectorias. Cada trayecto tiene el atributo AIGP y ahora gana la trayectoria con el atributo de métrica AIGP más bajo:

PE2#show bgp ipv4 unicast 10.100.1.1

BGP routing table entry for 10.100.1.1/32, version 6

Paths: (2 available, best #1, table default)

Advertised to update-groups:

5

Refresh Epoch 1

65000 65001

10.1.9.4 from 10.1.9.4 (10.100.1.4)

Origin incomplete, aigp-metric 6, localpref 100, valid, external, best

mpls labels in/out 18/17

rx pathid: 0, tx pathid: 0x0

Refresh Epoch 1

65000 65001

10.1.10.6 from 10.1.10.6 (10.100.1.6)

Origin incomplete, aigp-metric 11, localpref 100, valid, external

mpls labels in/out 18/30

rx pathid: 0, tx pathid: 0

Si la trayectoria que se recibe del router P3 es más larga que la que se recibe del router P4 en el router PE2, entonces el router PE2 sigue eligiendo la trayectoria del router P3 como la mejor. Puede aumentar la trayectoria que el router P3 anuncia en uno a través de un route-map y as-prepending.

router bgp 65000

address-family ipv4

neighbor 10.1.9.2 route-map as_path out

route-map as_path permit 10

set as-path prepend last-as 1

El router PE2 ahora tiene la ruta del router P3 con un AS adicional en la trayectoria AS:

PE2#show bgp ipv4 unicast 10.100.1.1

BGP routing table entry for 10.100.1.1/32, version 7

Paths: (2 available, best #1, table default)

Advertised to update-groups:

5

Refresh Epoch 1

65000 65001 65001

10.1.9.4 from 10.1.9.4 (10.100.1.4)

Origin incomplete, aigp-metric 6, localpref 100, valid, external, best

mpls labels in/out 18/nolabel

rx pathid: 0, tx pathid: 0x0

Refresh Epoch 1

65000 65001

10.1.10.6 from 10.1.10.6 (10.100.1.6)

Origin incomplete, aigp-metric 11, localpref 100, valid, external

mpls labels in/out 18/30

rx pathid: 0, tx pathid: 0

Debido al atributo de métrica AIGP, el router PE2 sigue eligiendo la trayectoria del router P3 como la mejor. La verificación AIGP se realiza antes de que se verifique la longitud de la trayectoria AS.

Si elimina la capacidad de enviar el AIGP en el router P4 hacia el router PE2, entonces el router PE2 recibe la trayectoria sin el atributo de métrica AIGP del router P4. Sin embargo, el router PE2 todavía tiene la trayectoria del router P3 con AIGP. El router PE2 prefiere la trayectoria con AIGP a una trayectoria sin AIGP, y elige la trayectoria del router P3 como la mejor:

PE2#show bgp ipv4 unicast 10.100.1.1

BGP routing table entry for 10.100.1.1/32, version 2

Paths: (2 available, best #2, table default)

Advertised to update-groups:

6

Refresh Epoch 1

65000 65001

10.1.10.6 from 10.1.10.6 (10.100.1.6)

Origin incomplete, localpref 100, valid, external

mpls labels in/out 17/30

rx pathid: 0, tx pathid: 0

Refresh Epoch 1

65000 65001 65001

10.1.9.4 from 10.1.9.4 (10.100.1.4)

Origin incomplete, aigp-metric 6, localpref 100, valid, external, best

mpls labels in/out 17/nolabel

rx pathid: 0, tx pathid: 0x0

Nota: Si desea que el router PE2 ignore el AIGP durante el proceso de selección del mejor trayecto BGP, configure el bgp bestpath aigp ignore comando.

Troubleshoot

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.