El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
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®.
No hay requisitos específicos para este documento.
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.
Esta sección proporciona una descripción general del atributo métrico AIGP y algunas consideraciones importantes con respecto a su uso.
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.
Cuando se utiliza AIGP, se realizan estos cambios en el Algoritmo de Selección de la Mejor Trayectoria de BGP:
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.
Si hay routers en la red que no son capaces de AIGP (routers heredados), hay dos soluciones posibles:
Esta sección describe cómo configurar el atributo de métrica 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
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
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
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.
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.
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
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.
Actualmente, no hay información específica de troubleshooting disponible para esta configuración.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
18-May-2021 |
Versión inicial |