Configurar o atributo de métrica AIGP para BGP

Introduction

Este documento descreve como configurar o atributo métrico do Protocolo de Gateway Interior Acumulado (AIGP - Acumulated Interior Gateway Protocol) que é transportado pelo Protocolo de Gateway de Borda (BGP - Border Gateway Protocol) no Cisco IOS^®.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

  

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

  

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.

Informações de Apoio

Esta seção fornece uma visão geral do atributo de métrica AIGP e algumas considerações importantes em relação ao seu uso.

Visão geral do atributo de métrica AIGP

As empresas podem desejar implementar um projeto de rede em que a rede é dividida com vários IGPs (Interior Gateway Protocols, protocolos de gateway interior), cada um com um sistema autônomo BGP. Isso é usado por razões de escalabilidade, em que a rede se torna muito grande para um IGP. O BGP ajuda a escalar quando transporta algumas das rotas que, de outra forma, seriam transportadas pelo IGP. A solução que usa o AIGP destina-se a redes com sistemas autônomos de BGP diferentes sob um controle administrativo.

Aqui está um exemplo:

O serviço de ponta a ponta é Multi-Protocol Label Switching (MPLS) VPN. Quando há um grande número de roteadores Provider Edge (PE) na rede, o IGP deve transportar muitas rotas. A solução é fazer com que o BGP transporte as interfaces de loopback dos roteadores PE. A solução usada para garantir que o caminho comutado de rótulo MPLS (LSP) não seja interrompido de ponta a ponta é usar o rótulo BGP IPv4 +. Isso significa que o RFC 3107 é usado entre os roteadores PE e os roteadores de borda, que conectam os diferentes domínios IGP.

O problema com essa solução é que os roteadores de borda ou os roteadores PE não podem mais tomar uma decisão sobre o melhor caminho, com base na métrica mais curta fim-a-fim, porque não há mais um IGP que roda em toda a rede. A solução para esse problema é o novo atributo BGP, chamado de Atributo Métrico IGP Acumulado ou atributo métrico AIGP. Este atributo não transitivo de BGP transporta a métrica acumulada para os caminhos de modo que os alto-falantes de BGP recebam conhecimento da métrica fim-a-fim para esses caminhos.

Os alto-falantes BGP devem adicionar a rota à métrica do próximo salto ao valor atual no atributo de métrica AIGP antes que a rota seja encaminhada.

Note: A comparação dos caminhos para uma rota é realizada imediatamente após a comparação da preferência local. Consulte o algoritmo de seleção de melhor caminho BGP documento da Cisco para obter mais detalhes sobre o algoritmo de seleção de melhor caminho BGP.

Essa solução é semelhante à solução em que o Discriminador de Múltiplas Saídas (MED) é definido como métrica IGP. No entanto, neste caso, a etapa 6 (o MED mais baixo) decide o melhor caminho. Essa etapa vem após a etapa 4, onde o caminho mais curto decide o melhor caminho. O melhor caminho já é encontrado com frequência antes de a etapa 6 ser atingida. Com a solução AIGP, a decisão BGP normal é alterada de modo que o AIGP seja verificado após a etapa 3 para determinar se a rota foi anunciada localmente. Se os sistemas autônomos (ASs) vizinhos diferentes forem iguais ao alto-falante BGP, isso significa que o valor always-compare-med deve ser ativado.

O atributo de métrica AIGP é especificado no RFC 7311, que é o Atributo de Métrica de IGP Acumulado para BGP. Para transportar o valor da métrica AIGP na comunidade de custos, os procedimentos especificados em draft-retana-idr-aigp-cost-community (Uso da Comunidade de Custos para transportar a Métrica de IGP Acumulada) são usados.

Note: A métrica AIGP atribuída ao BGP fornece roteamento ideal em redes onde diferentes domínios de roteamento são interconectados através do BGP.

Alterações no algoritmo de seleção de melhor caminho BGP

Quando o AIGP é usado, essas alterações no algoritmo de seleção de caminho do melhor BGP são feitas:

• O algoritmo de seleção de melhor caminho do BGP é modificado para comparar o AIGP imediatamente após a etapa 3 (rotas anunciadas localmente) e após a verificação do próximo salto é válido.
  
  
• Quando o roteador considera um caminho AIGP contra um caminho AIGP, o valor da métrica AIGP é adicionado à métrica em direção ao próximo salto.
  
  
• Quando o roteador considera um caminho AIGP contra um caminho não AIGP, o BGP prefere o caminho com o atributo AIGP por padrão.
  
  
• Quando a métrica IGP mais baixa é comparada ao salto seguinte do BGP, o custo do AIGP é levado em conta.
  
  
• Se a rota em direção ao próximo salto tiver uma métrica AIGP, a métrica será adicionada à métrica IGP em direção ao próximo salto. Essa soma é a nova métrica IGP (custo interior) para a rota. Isso ocorre quando uma rota BGP é recursiva para outra rota BGP.

Considerações importantes

Se os IGPs na rede forem de diferentes tipos (Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP)), é improvável que a métrica resultante do uso do atributo AIGP leve a resultados consistentes ou razoáveis. Se o mesmo IGP for usado em domínios diferentes, as mesmas configurações de métrica devem ser usadas para garantir resultados consistentes.

Para que os roteadores de borda ou os roteadores PE tenham a capacidade de decidir entre vários caminhos (com base na métrica derivada do AIGP), eles devem primeiro receber vários caminhos. Por esse motivo, talvez seja necessário habilitar o Caminho Adicional (ADD-Path) ou Anunciar o Melhor BGP Externo.

Os peers BGP que estão ativados para o AIGP e os que não estão são colocados em grupos de atualização separados. Além disso, os peers BGP que estão ativados para AIGP na comunidade de custos são colocados em grupos de atualização separados.

Solução para roteadores antigos

Se houver roteadores na rede que não possam usar o AIGP (roteadores herdados), então há duas soluções possíveis:

• Um roteador pode converter o AIGP em uma comunidade de custos, anexá-lo à rota e anunciar a rota para o roteador legado.
  
  
• Um roteador pode converter o AIGP para o MED, anexá-lo à rota e anunciar a rota para o roteador legado.

Configurar

Esta seção descreve como configurar o atributo de métrica AIGP.

Habilitar Transmissão do Atributo AIGP

O AIGP deve ser ativado explicitamente para sessões internas de BGP (iBGP) e externas de BGP (eBGP) com o comando neighbor ip-address aigp comando.

É assim que se verifica se o AIGP está ativado para o peer BGP:

P3#show bgp ipv4 unicast neighbors 10.1.9.2 | in AIGP

For address family: IPv4 Unicast

  AIGP is enabled

Originar o AIGP

O AIGP pode ser definido para a métrica IGP ou para um valor. Além disso, o AIGP pode ser definido para algumas rotas específicas somente para um IGP através de um route-map. Quando o originador do AIGP vê uma alteração na métrica do IGP, ele deve enviar uma nova atualização do BGP com os novos valores do AIGP para as rotas afetadas.

A métrica AIGP pode ser definida automaticamente para a métrica IGP ou para algum valor arbitrário de 32 bits:

P1(config-route-map)#set aigp-metric ?
  <0-4294967295>  manual value
  igp-metric      metric value from rib

Este exemplo mostra como definir a métrica AIGP para a métrica da rota 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ão para Desativar o Interrupção de tempo AIGP

Se esse botão estiver ativado, o BGP não usará a quebra de vínculo AIGP a menos que ambos os caminhos tenham o atributo de métrica AIGP. Isso significa que o atributo AIGP não é avaliado durante o processo de seleção do melhor caminho entre dois caminhos quando um caminho não tem o atributo AIGP.

Aqui está um exemplo:

router bgp 65000
  bgp bestpath aigp ignore

Solução para roteadores antigos

Se o roteador PE2 não tiver um software que suporte o atributo de métrica AIGP (é um roteador herdado), então há duas soluções que você pode usar.

Tradução do AIGP para a Comunidade de Custos

Configure os roteadores P3 e P4 para converter o custo IGP em uma comunidade de custos que o roteador pode anunciar para um roteador legado:

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

Você deve permitir que o roteador que envia envie envie comunidades estendidas. Isso significa que você deve especificar o send-community extended or send-community both atributos(neighbor x.x.x.x send-community) para o peer BGP.

Aqui está um exemplo:

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 mostrado, o roteador PE2 escolheu o caminho com o menor custo (100:6 versus 100:11) como o melhor caminho.

Tradução do AIGP para MED

Configure os roteadores P3 e P4 para converter o custo IGP no MED que o roteador pode anunciar para um roteador legado.

Aqui está a configuração no roteador 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

Aqui está a configuração no roteador 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

Verificar

A saída do comando debug bgp ipv4 unicast updates in mostra o uso do atributo de métrica 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

Ao visualizar a imagem fornecida na seção deste documento, você pode ver que todos os links na rede AS 6500 têm um custo OSPF de 10, os links entre os roteadores P1 e P4 e entre P2 e P3 têm um custo OSPF de 100, e o link entre os roteadores P3 e P1 tem um custo de 5.

Essa é a rota para 10.100.1.1/32, conforme vista no roteador 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

Essa é a rota para 10.100.1.1/32, conforme vista no roteador 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

Essa é a rota para 10.100.1.1/32, conforme vista no roteador 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

O melhor caminho no roteador P3 é o caminho com a métrica IGP 6, com o roteador P1 como o próximo salto. O melhor caminho no roteador P4 é o caminho com a métrica IGP 11, com o roteador P2 como o próximo salto. Os roteadores P3 e P4 enviam seu melhor caminho para o roteador PE2. O roteador PE2 escolhe o caminho do roteador P4 como o melhor, o que foi decidido porque ambos os caminhos BGP no roteador PE2 são muito semelhantes e a etapa 10 foi o empate-breaker: o caminho externo mais antigo ganhou. Isso significa que o tráfego do roteador PE2 para o roteador PE1 toma o caminho PE2-P4-P2-PE1. No entanto, o caminho geral mais curto, quando você considera o custo IGP, é PE2-P3-P1-PE1.

Use as informações a seguir para verificar o atributo de métrica AIGP nos roteadores P3 e P4 em direção ao roteador PE2 (10.100.1.7):

Esta é a saída para o roteador 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

Esta é a saída para o roteador 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

Você pode ver que o roteador P3 agora tem:

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

O roteador P4 agora tem:

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

A métrica IGP para os caminhos nos roteadores P3 e P4 não foi alterada, mas o roteador PE2 agora recebe as rotas com o atributo AIGP dos roteadores P3 e P4.

O roteador PE2 vê os dois caminhos. Cada caminho tem o atributo AIGP e o caminho com o atributo de métrica AIGP mais baixo agora ganha:

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

Se o caminho recebido do roteador P3 for maior que o caminho recebido do roteador P4 no roteador PE2, o roteador PE2 ainda escolhe o caminho do roteador P3 como o melhor. Você pode aumentar o caminho que o roteador P3 anuncia em um por meio de um route-map e 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

O roteador PE2 agora tem a rota do roteador P3 com um AS extra no caminho 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

Devido ao atributo de métrica AIGP, o roteador PE2 ainda escolhe o caminho do roteador P3 como o melhor. A verificação do AIGP é executada antes que o comprimento do caminho do AS seja verificado.

Se você remover a capacidade de enviar o AIGP no roteador P4 para o roteador PE2, o roteador PE2 recebe o caminho sem o atributo de métrica AIGP do roteador P4. No entanto, o roteador PE2 ainda tem o caminho do roteador P3 com AIGP. O roteador PE2 prefere o caminho com AIGP em um caminho sem AIGP e escolhe o caminho do roteador P3 como o melhor:

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

Note: Se desejar que o roteador PE2 ignore o AIGP durante o processo de seleção do melhor caminho do BGP, configure o bgp bestpath aigp ignore comando.

Troubleshoot

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.