Cómo Optimizar BGP Path Usando AIGP

Introducción

Este documento describe qué es la métrica del Protocolo de gateway interior acumulado (AIGP) en el Protocolo de gateway fronterizo (BGP) y sus casos de uso.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• BGP
• Red de conmutación de etiquetas multiprotocolo (MPLS) sin problemas

Componentes Utilizados

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

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si nuestra red está activa, asegúrese de comprender el impacto potencial de cualquier comando.

Antecedentes

Esta sección proporciona una descripción general de la métrica AIGP y algunas consideraciones importantes con respecto a su uso.

Como sabe, IGP significa Interior Gateway Protocol y representa un grupo de protocolos de ruteo que se ejecutan dentro de un único dominio administrativo. IGP toma una decisión de selección de trayectoria basada en el valor de la métrica.

BGP está diseñado para proporcionar routing a través de un gran número de sistemas autónomos independientes (AS) con una coordinación limitada o nula entre las respectivas administraciones. No toma sus decisiones de selección de trayectoria mediante el uso de una métrica. Sin embargo, hay implementaciones en las que una sola administración ejecuta varias redes BGP contiguas. En tales casos, puede ser deseable dentro de ese dominio administrativo único, que BGP seleccione las trayectorias basadas en una métrica, tal como lo haría un IGP.

Atributo de protocolo de gateway interior acumulado

La métrica AIGP (definida a través de RFC7311) es un atributo de trayecto BGP no transitivo opcional. El campo de valor del atributo AIGP se define como un conjunto de elementos Tipo/Longitud/Valor (TLV). El BGP AIGP TLV contiene la Métrica IGP Acumulada.

Ejemplos de casos prácticos

1. Red de varios ASN

Hoy en día, hay muchas redes que se encuentran en un único dominio administrativo, que se subdividen en varios ASN por diversas razones. Podría haber muchas razones posibles para ello:

• escala IGP
• Otro proveedor de red compró una red de proveedor, pero aún así, no han fusionado sus ASN de BGP internamente
• Las distintas divisiones empresariales tienen su propia red interna
• Confederaciones BGP con Sub-AS
• MPLS perfecto, etc.

En redes como estas, puede ser útil permitir que BGP tome sus decisiones basadas en la métrica IGP, de modo que BGP elija la trayectoria de extremo a extremo más corta entre dos nodos, incluso si los nodos están en dos ASN diferentes.

Por ejemplo: red ABC, que se subdivide en dos ASN de BGP, ASN 1 y ASN 2. Están observando el ASBR y los costos de IGP de link representan el ancho de banda. El objetivo aquí es tener una ruta óptima de extremo a extremo entre PE11 y PE21.

Red de varios ASN sin AIGP

PE11#sh bgp ipv4 unicast 10.0.21.21/32
BGP routing table entry for 10.0.21.21/32, version 20
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 3
  2
    192.168.0.12 (metric 211) from 192.168.11.11 (192.168.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 192.168.0.12, Cluster list: 192.168.11.11
      rx pathid: 0x1, tx pathid: 0
  Refresh Epoch 3
  2
    192.168.0.11 (metric 201) from 192.168.11.11 (192.168.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 192.168.0.11, Cluster list: 192.168.11.11
      rx pathid: 0x0, tx pathid: 0x0

Con AiGP habilitado en la topología (en PE11, PE32, ASBR1x, ASBR2x, RR1, RR2), PE11 ahora elige la trayectoria con el costo de IGP de extremo a extremo más bajo.

Red de varios ASN con AIGP

Configuración

PEx, ASBRx y RRn:

Configuración de la capacidad AIGP:

router bgp ASN
 neighbor <NBR_IP> aigp
!

Anuncie la métrica AIGP para un prefijo.

PE21:

route-map SET_AIGP permit 10
 set aigp-metric igp-metric
!
router bgp 2
 address-family {ipv4|ipv6} unicast
  network 10.0.21.21 mask 255.255.255.255 route-map SET_AIGP
!

Verificación

PE11#sh bgp ipv4 unicast 10.0.21.21/32    
BGP routing table entry for 10.0.21.21/32, version 21
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 3
  2
    192.168.0.11 (metric 201) from 192.168.11.11 (192.168.11.11)
      Origin IGP, aigp-metric 501, metric 0, localpref 100, valid, internal
      Originator: 192.168.0.11, Cluster list: 192.168.11.11
      rx pathid: 0x1, tx pathid: 0
  Refresh Epoch 3
  2
    192.168.0.12 (metric 211) from 192.168.11.11 (192.168.11.11)
Origin IGP, aigp-metric 201, metric 0, localpref 100, valid, internal, best
      Originator: 192.168.0.12, Cluster list: 192.168.11.11
      rx pathid: 0x0, tx pathid: 0x0

2. MPLS sin fisuras (ASN único)

En una red central de proveedor de servicios de gran tamaño, la red de transporte suele subdividirse en diferentes dominios IGP, unidos mediante la unidifusión etiquetada BGP para proporcionar una ruta conmutada (LSP) de extremo a extremo. Los routers de borde realizan Next Hop Self (NHS) en BGP LU AF.

IGP/LDP transporta la información de prefijo/etiqueta solamente en el área/dominio local. Luego, BGP lleva el prefijo/etiqueta a todas las áreas/dominios remotos redistribuyendo las rutas en BGP en los límites de área. Las rutas/etiquetas se anuncian entonces usando LSPs. El salto siguiente para la ruta se cambia en cada ABR al router local, lo que elimina la necesidad de fugas de rutas IGP a través de los límites del área/dominio.

En este diagrama de topología, hay un único dominio BGP dividido en 2 dominios IGP (CORE y Access-1). El número que se muestra junto a cada link representa la métrica/costo IGP de ese link.

Red MPLS perfecta sin AIGP

Reto: el tráfico descendente de PS-Core a eNB/gNB (conectado a CSR15) está tomando una ruta asimétrica y subóptima en comparación con el tráfico ascendente de eNB/gNB (conectado a CSR15) hacia PS-Core, lo que está causando problemas de latencia en el tráfico de movilidad.

‘Observaciones’

1. Se observa principalmente en escenarios de borde geográfico donde el mismo router de agregación actúa como un router de borde común para varios dominios de acceso (por ejemplo, AGG102 en la imagen mencionada anteriormente).
2. Para el tráfico ascendente, el router de sitio de celda (CSR) elige el router de borde más cercano. Por ejemplo, CSR15 selecciona AGG102 como NextHop.
3. Para el tráfico descendente, el router de agregación de servicios (SAR) también elige el router de borde más cercano. Por ejemplo, SAR150 selecciona AGG101 (coste 180 < 200).

Registros del dispositivo: inicial

Tráfico ascendente: CSR15 a SAR150

RP/0/0/CPU0:CSR15#traceroute mpls ipv4 10.0.2.150/32 so 10.0.2.15
Tracing MPLS Label Switched Path to 10.0.2.150/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.15.102.15 MRU 1500 [Labels: explicit-null/16150 Exp: 0/0]
L 1 10.15.102.102 MRU 1500 [Labels: 16150 Exp: 0] 0 ms                !!!! AGG102
. 2 *                                                                 !!!! P112 does not have a route to CSR15
! 3 10.112.150.150 20 ms                                              !!!! SAR150

Tráfico descendente: SAR150 a CSR15

RP/0/0/CPU0:SAR150#traceroute mpls ipv4 10.0.2.15/32 source 10.0.2.150
Tracing MPLS Label Switched Path to 10.0.2.15/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.101.150.150 MRU 1500 [Labels: explicit-null/16015 Exp: 0/0]
L 1 10.101.150.101 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                 !!! AGG101
L 2 10.11.101.11 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                   !!! CSR11
L 3 10.11.12.12 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                    !!! CSR12
L 4 10.12.13.13 MRU 1500 [Labels: 16015 Exp: 0] 20 ms                    !!! CSR13             
L 5 10.13.14.14 MRU 1500 [Labels: explicit-null Exp: 0] 30 ms            !!! CSR14
! 6 10.14.15.15 30 ms                                                    !!! CSR15

Solución AIGP

El objetivo aquí es tener una trayectoria óptima de extremo a extremo entre los routers SAR y los routers CSR. El BGP etiquetado Unicast (RFC 3107) se utiliza para calcular la distancia de SAR a los routers CSR. El ancho de banda disponible en cada uno de los links de núcleo se asigna al costo IGP, por lo tanto, BGP debe transportar este costo correctamente entre cada uno de los PE. Esta funcionalidad se logra mediante el uso de AiGP.

Red MPLS sin problemas con AIGPed MPLS sin problemas con AIGP

Configuración

La capacidad AiGP Path Attribute debe ser acordada entre los peers BGP. Las métricas de AiGP sólo se incluyen en los anuncios de prefijo entre los peers habilitados para AiGP. La capacidad AIGP se configura para un par BGP individual y una familia de direcciones BGP específica.

router bgp ASN
 neighbor <NBR_IP>
  address-family ipv4 unicast
   aigp [disable]

La métrica AIGP es un valor de 32 bits (de 0 a 4.294.967.295). Se puede establecer durante la redistribución, la creación de rutas a través de una sentencia de red o durante la recepción de un prefijo con un route map/route-policy.

route-policy AIGP_POLICY
  set aigp-metric igp-cost
end-policy
!
router bgp ASN
 address-family {ipv4|ipv6} unicast
  network <NETWORK/MASK> route-policy AIGP_POLICY
  or
  redistribute {ospf|isis} {process-id} route-policy AIGP_POLICY metric VALUE
!

Configuración de muestra:

CSR15:
! Additional config lines related to AIGP are marked in RED color
route-policy SID($SID)
 set label-index $SID
 set aigp-metric igp-cost
end-policy
!
router bgp 1
 address-family ipv4 unicast
  network 10.0.2.15/32 route-policy SID(15)
 neighbor-group RR
  address-family ipv4 labeled-unicast
   aigp
  !
 !
!

Registros de dispositivos: después de la implementación de AIGP

Tráfico descendente: SAR150 a CSR15

RP/0/0/CPU0:SAR150#sh bgp ipv4 labeled-unicast 10.0.2.15/32
BGP routing table entry for 10.0.2.15/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 411 411
Local Label: 16015
Last Modified: Oct 24 11:05:26.796 for 00:00:04
Paths: (2 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.0.2.102 (metric 200) from 10.0.2.100 (10.0.2.15)
Received Label 16015 
Origin IGP, metric 0, localpref 100, aigp metric 20, valid, internal, best, group-best, labeled-unicast
Received Path ID 1, Local Path ID 1, version 410
Originator: 10.0.2.15, Cluster list: 10.0.2.100, 10.0.2.102
Total AIGP metric 220
Label-Index: 15
Path #2: Received by speaker 0
Not advertised to any peer
Local
10.0.2.101 (metric 180) from 10.0.2.100 (10.0.2.15)
Received Label 16015 
Origin IGP, metric 0, localpref 100, aigp metric 60, valid, internal, backup, add-path, labeled-unicast
Received Path ID 8, Local Path ID 7, version 411
Originator: 10.0.2.15, Cluster list: 10.0.2.100, 10.0.2.101
Total AIGP metric 240
Label-Index: 15

RP/0/0/CPU0:SAR150#traceroute mpls ipv4 10.0.2.15/32 so 10.0.2.150
Tracing MPLS Label Switched Path to 10.0.2.15/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.112.150.150 MRU 1500 [Labels: 16102/16015 Exp: 0/0]
L 1 10.112.150.112 MRU 1500 [Labels: explicit-null/16015 Exp: 0/0] 10 ms          !!! P112
L 2 10.102.112.102 MRU 1500 [Labels: explicit-null Exp: 0] 10 ms                  !!! AGG102
! 3 10.15.102.15 20 ms                                                            !!! CSR15

Tráfico ascendente: CSR15 a SAR150

RP/0/0/CPU0:CSR15#traceroute mpls ipv4 10.0.2.150/32 source 10.0.2.15
Tracing MPLS Label Switched Path to 10.0.2.150/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.15.102.15 MRU 1500 [Labels: explicit-null/16150 Exp: 0/0]
L 1 10.15.102.102 MRU 1500 [Labels: 16150 Exp: 0] 10 ms                 !!! AGG102
. 2 *                                                                   !!! P112 does not have a route to CSR15
! 3 10.112.150.150 30 ms                                                !!! SAR150

Puntos a considerar

• Con los cambios en el costo de IGP (por ejemplo, el cambio en la topología física debido al corte de link y más), también hay cambios correspondientes en BGP. Esto podría causar la pérdida de la ruta BGP. Esta convergencia también depende del valor de retraso del disparador de siguiente salto BGP configurado para los eventos no críticos.
• Al introducir AiGP, se modifica la selección de la mejor trayectoria de BGP. Pone BGP AIGP después de la preferencia local de BGP y antes del atributo AS_PATH. Por lo tanto, si hay alguna política existente sobre AS_PATH pendiente, es posible que deba revisarse.
• Cuando hay dos trayectorias, una con la métrica AIGP y la otra sin, BGP siempre prefiere una trayectoria con la métrica AIGP.

Ignorar AIGP

Un dispositivo que ejecuta el protocolo de gateway fronterizo (BGP) también se puede configurar para ignorar la métrica AIGP durante el proceso de selección de la mejor trayectoria entre dos trayectorias cuando una trayectoria no tiene la métrica AIGP. Uso del bgp bestpath aigp ignore comando en el modo de configuración del router. Para devolver el dispositivo a la operación predeterminada, utilice la forma no de este comando.

[no] bgp bestpath aigp ignore

De forma predeterminada, BGP siempre prefiere una trayectoria con la métrica AIGP. Cuando hay dos trayectorias, una con la métrica AIGP y la otra sin, la ejecución del bgp bestpath aigp ignore comando hace que BGP realice el cálculo de la mejor trayectoria como si ninguna trayectoria tuviera la métrica AIGP.

Conclusión

El atributo BGP AIGP está ciertamente desarrollado para resolver ciertos casos prácticos de nicho, pero debe usarse con precaución.

Información Relacionada

• Configuración del Atributo de Métrica AIGP para BGP
• Soporte técnico y descargas de Cisco