IP : Border Gateway Protocol (BGP)

Configurar o atributo de métrica AIGP para o BGP

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (21 Abril 2016) | Feedback

Introdução

Este documento descreve como configurar o atributo de métrica acumulado do protocolo Interior Gateway Protocols (AIGP) que é levado pelo Border Gateway Protocol (BGP) no ® do Cisco IOS.

Contribuído por Luc De Ghein, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

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.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Informações de Apoio

Esta seção fornece uma vista geral do atributo de métrica AIGP e de algumas considerações importantes com respeito a seu uso.

Vista geral do atributo de métrica AIGP

As empresas puderam desejar executar um projeto de rede onde a rede fosse rachada com protocolos Interior Gateway Protocols múltiplos (IGP), cada um com um sistema autônomo BGP. Isto é usado para os motivos de escalabilidade, onde a rede se torna demasiado grande para um IGP. O BGP ajuda a escalar quando leva algumas das rotas que estariam levadas de outra maneira pelo IGP. A solução que usa AIGP é pretendida para redes com sistemas autônomo diferentes BGP sob um controle administrativo.

Aqui está um exemplo:

O serviço de ponta a ponta é (MPLS) VPN Multiprotocol Label Switching. Quando há um grande número Roteadores da ponta de provedor (PE) na rede, o IGP deve levar rotas demais. A solução é mandar o BGP levar as interfaces de loopback dos roteadores de PE. A solução que é usada a fim se assegurar de que o caminho comutado por rótulo MPLS (LSP) não seja fim-a-fim interrompido é usar o IPv4 + a etiqueta BGP. Isto significa que o RFC 3107 está usado entre os roteadores de PE e os roteadores de borda, que conecta os domínios IGP diferentes.

A edição com esta solução é que os roteadores de borda ou os roteadores de PE podem já não tomar uma decisão sobre o melhor caminho, com base no fim-a-fim métrico o mais curto, porque há já não um IGP que é executado durante todo a rede inteira. A solução a esta edição é os atributos de BGP novos, chamados o atributo de métrica acumulado IGP ou atributo de métrica AIGP. Este atributo NON-transitivo BGP leva a métrica acumulada para os trajetos de modo que os auto-falantes de BGP recebam o conhecimento da métrica fim-a-fim para aqueles trajetos.

Os auto-falantes de BGP devem adicionar a rota à métrica do salto seguinte ao valor atual no atributo de métrica AIGP antes que a rota esteja enviada.

Nota: A comparação dos trajetos para uma rota é executada imediatamente depois da comparação da preferência local. Refira o documento Cisco do algoritmo de seleção de caminho do melhors BGP para mais detalhes sobre o algoritmo de seleção de caminho do melhors BGP.

Esta solução é similar à solução onde o Multi Exit Discriminator (MED) é ajustado à métrica IGP. Contudo, neste caso, a etapa 6 (o mais baixo MED) decide o melhor caminho. Esta etapa vem após etapa 4, onde o caminho mais curto decide o melhor caminho. O melhor caminho frequentemente é encontrado já antes que a etapa 6 esteja alcançada. Com a solução AIGP, a decisão normal BGP é mudada de modo que o AIGP seja verificado depois que etapa 3 a fim determinar se a rota esteve anunciada localmente. Se os sistemas independentes de vizinho diferentes (AS) espreitam com o auto-falante de BGP, significa que o valor do always-compare-med deve ser permitido.

O atributo de métrica AIGP é especificado no RFC 7311, que é o atributo de métrica acumulado IGP para o BGP. A fim levar o valor de métrica AIGP na comunidade do custo, os procedimentos especificados na esboço-retana-idr-aigp-custo-comunidade (uso da comunidade do custo levar a métrica acumulada IGP) são usados.

Nota: A métrica BGP AIGP atribuída fornece o roteamento ótimo nas redes onde os domínios de roteamento diferentes são interconectados com o BGP.

Mudanças ao algoritmo de seleção de caminho do melhors BGP

Quando AIGP é usado, estas mudanças ao algoritmo de seleção de caminho do melhors BGP estão feitas:

  • O algoritmo de seleção de caminho do melhors BGP é alterado a fim comparar o AIGP imediatamente depois de etapa 3 (localmente rotas anunciadas) e depois que a verificação do salto seguinte é válida.

  • Quando o roteador considera um trajeto AIGP contra um trajeto AIGP, a seguir o valor da métrica AIGP está adicionado à métrica para o salto seguinte.

  • Quando o roteador considera um trajeto AIGP contra um trajeto NON-AIGP, a seguir o BGP prefere o trajeto com o atributo AIGP à revelia.

  • Quando a mais baixa métrica IGP é comparada ao salto seguinte BGP, a seguir o custo AIGP está levado em consideração.

  • Se a rota para o salto seguinte tem uma métrica AIGP, a métrica está adicionada à métrica IGP para o salto seguinte. Esta soma é a métrica nova IGP (custos interiores) para a rota. Isto ocorre quando uma rota de BGP é recursivo a uma outra rota de BGP.

Considerações importantes

Se os IGP na rede são de tipos diferentes (Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), o Enhanced Interior Gateway Routing Protocol (EIGRP)), é improvável que a métrica que resulta do uso do atributo AIGP conduz aos resultados consistentes ou apreciáveis. Se o mesmo IGP é usado nos domínios diferentes, a seguir os mesmos ajustes métricos devem ser usados a fim garantir resultados consistentes.

Para que os roteadores de borda ou os roteadores de PE tenham a capacidade para decidir entre os caminhos múltiplos (baseados na métrica derivada AIGP) devem primeiramente receber caminhos múltiplos. Por este motivo, você pôde ser exigido permitir o trajeto adicional (Adicionar-PATH) ou anunciar a melhor característica do BGP externo.

Os bgp peer que são permitidos para AIGP e aqueles que não são são colocados em grupos separados da atualização. Adicionalmente, os bgp peer que são permitidos para AIGP na comunidade do custo são colocados em grupos separados da atualização.

Solução para o Roteadores do legado

Se há o Roteadores na rede que não é capaz de AIGP (Roteadores do legado), a seguir há duas soluções possíveis:

  • Um roteador pode traduzir o AIGP a uma comunidade do custo, anexá-lo à rota, e anunciar a rota ao roteador do legado.

  • Um roteador pode traduzir o AIGP ao MED, anexá-lo à rota, e anunciar a rota ao roteador do legado.

Configurar

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

Permita a transmissão do atributo AIGP

O AIGP deve ser permitido explicitamente para o Internal BGP (iBGP) e as sessões do BGP externo (eBGP) com o aigp vizinho do IP address comandam.

Isto é como verificar se o AIGP está permitido para o bgp peer:

P3#show bgp ipv4 unicast neighbors 10.1.9.2 | in AIGP

For address family: IPv4 Unicast

  AIGP is enabled

Origine o AIGP

O AIGP pode ser ajustado à métrica IGP ou a um valor. Também, o AIGP pode ser ajustado para algumas rotas particular somente para um IGP através de um mapa de rotas. Quando o autor do AIGP vê uma mudança na métrica IGP, deve enviar uma atualização BGP nova com os valores novos AIGP para as rotas afetadas.

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

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

Este exemplo mostra como ajustar o AIGP métrico à 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 desabilitar a Laço-quebra AIGP

Se este botão é permitido, a seguir o BGP não usa AIGP quequebra a menos que ambos os trajetos tiverem o atributo de métrica AIGP. Isto significa que o atributo AIGP não está avaliado durante o processo de seleção do melhor caminho entre dois trajetos quando um trajeto não tem o atributo AIGP.

Aqui está um exemplo:

router bgp 65000
  bgp bestpath aigp ignore

Solução para o Roteadores do legado

Se o roteador que o PE2 não tem o software que apoia o atributo de métrica AIGP (ele é um roteador do legado), a seguir há duas soluções que você pode usar.

Tradução do AIGP para custar a comunidade

Configurar o Roteadores P3 e P4 a fim traduzir o IGP custam em uma comunidade do custo que o roteador possa anunciar a um roteador do 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 o roteador que envia para enviar as comunidades extendida. Isto significa que você deve especificar a enviar-comunidade estendida ou a enviar-comunidade ambos os atributos (a enviar-comunidade vizinha x.x.x.x) para o bgp peer.

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 trajeto com o mais barato (100:6 contra 100:11) como o melhor caminho.

Tradução do AIGP ao MED

Configurar o Roteadores P3 e P4 a fim traduzir o IGP custam no MED que o roteador pode anunciar a um roteador do legado.

Está aqui 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

Está aqui 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 das atualizações do unicast do IPv4 BGP debugar no comando 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

Quando você vê a imagem fornecida na seção de visão geral do atributo de métrica AIGP deste documento, você pode ver que todos os links na rede COMO 6500 têm uns custos de OSPF do 10, os links entre o Roteadores P1 e P4 e entre o P2 e o P3 tenha uns custos de OSPF de 100, e o link entre o Roteadores P3 e P1 tem um custo do 5.

Esta é a rota para 10.100.1.1/32, como visto 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

Esta é a rota para 10.100.1.1/32, como visto 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

Esta é a rota para 10.100.1.1/32, como visto 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 trajeto com a métrica 6 IGP, com o roteador P1 como o salto seguinte. O melhor caminho no roteador P4 é o trajeto com a métrica 11 IGP, com o roteador P2 como o salto seguinte. O Roteadores P3 e P4 envia seu melhor caminho para o roteador PE2. O roteador PE2 escolhe o trajeto do roteador P4 como melhor, que foi decidido porque ambos os trajetos BGP no roteador PE2 são muito similares e a etapa 10 era o tiebreaker: o trajeto externo o mais velho ganhado. Isto significa que o tráfego do roteador PE2 ao roteador PE1 toma o trajeto PE2-P4-P2-PE1. Contudo, o trajeto total o mais curto, quando você considera o IGP custar, é PE2-P3-P1-PE1.

Use a informação que segue a fim verificar o atributo de métrica AIGP no Roteadores P3 e P4 para o roteador PE2 (10.100.1.7):

Está aqui 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

Está aqui 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 tem agora:

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 tem agora:

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 trajetos no Roteadores P3 e P4 não mudou, mas o roteador PE2 recebe agora as rotas com o atributo AIGP do Roteadores P3 e P4.

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

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 trajeto que está recebido do roteador P3 é mais longo do que o trajeto que está recebido do roteador P4 no roteador PE2, a seguir o roteador PE2 ainda escolhe o trajeto do roteador P3 como o melhor. Você pode aumentar o trajeto que o roteador P3 anuncia por um através de um mapa de rotas e de como-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 tem agora a rota do roteador P3 com um acréscimo TÃO no QUANTO o trajeto:

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 trajeto do roteador P3 como o melhor. A verificação AIGP está executada antes que ENQUANTO o comprimento de trajeto é verificado.

Se você remove a capacidade para enviar o AIGP no roteador P4 para o roteador PE2, a seguir o roteador PE2 recebe o trajeto sem o atributo de métrica AIGP do roteador P4. Contudo, o roteador PE2 ainda tem o trajeto do roteador P3 com AIGP. O roteador PE2 prefere o trajeto com AIGP sobre um trajeto sem AIGP, e escolhe o trajeto 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

Nota: Se você quer o roteador PE2 ignorar o AIGP durante o processo de seleção do melhor caminho BGP, a seguir configurar o comando ignore do aigp do melhor caminho BGP.

Troubleshooting

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



Document ID: 119001