Selecionar algoritmo de melhor caminho BGP

Introdução

Este documento descreve a função do algoritmo de melhor caminho do Border Gateway Protocol (BGP). 

Informações de Apoio

Os roteadores BGP normalmente recebem vários caminhos para o mesmo destino. O algoritmo do melhor caminho BGP decide qual é o melhor caminho a instalar na tabela de IP Routing e a se usar para o encaminhamento de tráfego.

Porque os roteadores ignoram trajetos

Supor que todos os trajetos que um roteador recebe para um prefixo particular estão arranjados em uma lista. A lista é similar à saída do comando show ip bgp longer-prefixes. Neste caso, alguns trajetos não são considerados como candidatos para o melhor caminho. Tais trajetos tipicamente não têm a bandeira válida na saída do comando show ip bgp longer-prefixes. Os roteadores ignoram trajetos nestas circunstâncias:

• Caminhos marcados como não sincronizados na saída show ip bgp longer-prefixes.

  Se a sincronização de BGP é permitida, deve haver um fósforo para o prefixo na tabela de IP Routing para que um trajeto do Internal BGP (iBGP) esteja considerado um caminho válido. Originalmente, a sincronização BGP era habilitada por padrão no Cisco IOS^® Software. Se a rota correspondente for aprendida com um vizinho Open Shortest Path First (OSPF), a ID do roteador OSPF deverá corresponder à ID do roteador BGP do vizinho iBGP. A maioria de usuários preferem desabilitar a sincronização com uso do subcomando BGP no synchronization.

  Note: A sincronização é desativada por padrão no Cisco IOS® Software Release 12.2(8)T e posteriores.

• Trajetos para que o Próximo salto seja inacessível.

  Assegure-se que há uma rota do protocolo Interior Gateway Protocols (IGP) ao Próximo salto que é associado com o trajeto.

• Trajetos de um vizinho do BGP externo (eBGP) se o sistema autônomo local aparece no AS_PATH. 

  Esses caminhos são negados após o ingresso no roteador e nem são instalados no BGP Routing Information Base (RIB). O mesmo se aplica a qualquer caminho que seja negado por uma política de roteamento que seja implementada via acesso, prefixo, AS_PATH ou listas de comunidade, a menos que você tenha configurado neighbor soft-reconfiguration inbound para o vizinho.

• Se você habilitou bgp enforce-first-as e UPDATE não contém o AS do vizinho como o primeiro número AS no AS_SEQUENCE.

  Neste caso, o roteador envia uma notificação e fecha a sessão.

• Caminhos marcados como (received-only) na saída show ip bgp longer-prefixes

  A política rejeitou estes trajetos. No entanto, o roteador armazenou os caminhos porque você configurou para o vizinho que envia o caminho.soft-reconfiguration inbound

Como funciona o algoritmo de melhor caminho

O BGP atribui o primeiro caminho válido como o melhor caminho atual. O BGP compara então o melhor caminho com o trajeto seguinte na lista, até que o BGP alcance a extremidade da lista de caminhos válidos. Esta lista fornece as regras usadas para determinar o melhor caminho:

1. Prefira o trajeto com o PESO o mais alto. 

   Note: O PESO é um parâmetro específico da Cisco. É local ao roteador em que é configurado.

2. Prefira o trajeto com o LOCAL_PREF mais alto.

   Note: Um trajeto sem LOCAL_PREF é considerado ter tido o conjunto de valores com o comando bgp default local-preference, ou para ter um valor de 100 à revelia.

3. Prefira o trajeto que foi originado localmente através de uma rede ou de um comando bgp subcommand agregado ou com a redistribução de um IGP.

   Os caminhos locais que são originado pela rede ou pelos comandos redistribute são preferidos sobre os agregados locais que são originado pelo comando aggregate-address.

   Note: Esteja ciente deste item:
   
   Se o AIGP estiver configurado E o comando bgp bestpath aigp ignore não estiver configurado, o processo de decisão considerará a métrica do AIGP. Consulte Configurar o atributo de métrica AlGP para BGP para obter mais detalhes.

4. Prefira o trajeto com o AS_PATH mais curto.

   Note: Esteja ciente destes artigos:
   -Esta etapa é saltada se você configurou o comando bgp bestpath as-path ignore.
   -Um AS_SET conta como 1, não importa como muitos AS estão no grupo.
   -O AS_CONFED_SEQUENCE e os AS_CONFED_SET não são incluídos do comprimento AS_PATH.

5. Prefira o trajeto com o mais baixo tipo da origem.

   Note: O IGP é mais baixo do que o Protocolo de Gateway Exterior (EGP), e o EGP é mais baixo do que INCOMPLETO.

6. Prefira o trajeto com o mais baixo Multi-Exit Discriminator (MED).

   Note: Esteja ciente destes artigos:
   
   -Esta comparação ocorre somente se o primeiro (o vizinho) AS é a mesma nos dois trajetos. Todo os sub-AS da confederação são ignorados.
   Ou seja, os MED são comparados somente se o primeiro AS no AS_SEQUENCE é o mesmo para caminhos múltiplos. Qualquer AS_CONFED_SEQUENCE anterior é ignorado.
   
   -Se o bgp always-compare-medé habilitado, os MED estão comparados para todos os trajetos.
   Você deve desabilitar esta opção sobre o todo o AS. Se não, os loop de roteamento podem ocorrer.
   
   -Se o bgp bestpath med-confed é habilitado, os MED são comparados para todos os trajetos que consistem somente no AS_CONFED_SEQUENCE.
   Estes trajetos originados dentro da confederação local.
   
   - O MED dos caminhos recebidos de um vizinho com um MED de 4.294.967.295 é alterado antes da inserção na tabela BGP. O MED muda para 4.294.967.294.
   
   - Os MED dos caminhos recebidos de um vizinho com um MED de 4.294.967.295 são considerados válidos e inseridos na tabela BGP com efeito para os códigos corrigidos da Cisco bug ID CSCef34800.
   
   -Os trajetos recebidos sem o MED estão atribuídos um MED de 0, a menos que você permitir o MED do melhor caminho BGP faltante-como-ruim.
   Se você permitiu o MED do melhor caminho BGP faltante-como-ruim, os trajetos estão atribuídos um MED de 4.294.967.294.
   Se você ativou o erro de melhor caminho de bgp em falta como pior, os caminhos recebem um MED de 4.294.967.295 com efeito para os códigos corrigidos para o ID de bug da Cisco CSCef34800.
   
   O comando bgp deterministic-med também pode influenciar esta etapa.
   Refira a como os BGP Router usam o Multi-Exit Discriminator para a seleção do melhor caminho para uma demonstração.

7. Prefira o eBGP sobre trajetos do iBGP.

   Se o melhor caminho é selecionado, vá para Passo 9 (multipath).

   Note: Os trajetos que contêm o AS_CONFED_SEQUENCE e o AS_CONFED_SET são locais à confederação. Conseqüentemente, estes trajetos são tratados como trajetos internos. Não há nenhuma distinção entre a confederação externo e a confederação interna.

8. Prefira o trajeto com o mais baixo IGP métrico ao salto seguinte BGP.

   Continue, mesmo se o melhor caminho é selecionado já.

9. Determine se os caminhos múltiplos exigem a instalação na tabela de roteamento para o multipath de BGP.

   Continue, se o melhor caminho não for selecionado ainda.

10. Quando ambos os trajetos são externos, prefira o trajeto que foi recebido primeiramente (o mais velho).

    Esta etapa minimiza o rota-flap porque um trajeto mais novo não desloca o mais velho, mesmo se o trajeto mais novo seja a rota preferida baseada nos critérios de decisão seguintes (etapas 11, 12, e 13).

    Salte esta etapa se qualquer dos artigos forem verdadeiros:

    • Você permitiu o comando bgp best path compare-routerid.

      Note: Os Cisco IOS® Software Releases 12.0.11S, 12.0.11SC, 12.0.11S3, 12.1.3, 12.1.3AA, 12.1.3.T e 12.1.3.E introduziram este comando.

    • O Router ID é o mesmo para caminhos múltiplos porque as rotas foram recebidas do mesmo roteador.

    • Não há nenhum melhor caminho atual.

      O melhor caminho atual pode ser perdido quando, por exemplo, o vizinho que oferece o trajeto vai para baixo.

11. Prefira a rota que vem do Roteador BGP com a mais baixa identificação do roteador

    Se não for configurado manualmente, o ID do roteador será selecionado como o maior endereço IP em uma interface de loopback. Se não existirem interfaces de loopback, ele será selecionado como o maior endereço IP em uma interface física ativa. Você pode usar o comando bgp router-id para definir manualmente o ID do roteador.

    Note: Se um trajeto contem atributos do refletor de rota (RR), o identificador de originador está substituído para o Router ID no processo de seleção do caminho.

12. Se o autor ou o Router ID forem os mesmos caminhos múltiplos, prefira o trajeto com o tamanho mínimo da lista de cluster.

    Isto está somente presente em ambientes BGP RR. Permite que os clientes espreitem com RR ou clientes em outros conjuntos. Neste cenário, o cliente deve estar ciente dos atributos de BGP RR-específicos.

13. Prefira o trajeto que vem do mais baixo endereço vizinho.

    Esse endereço é o endereço IP usado na configuração de do BGP.neighbor O endereço corresponde ao peer remoto que é usado na conexão de TCP com o roteador local.

Exemplo: Seleção do melhor caminho BGP

Neste exemplo, 9 caminhos estão disponíveis para a rede 10.30.116.0/23. O comando show ip bgp network exibe as entradas na tabela de roteamento BGP para a rede especificada.

Router R1#show ip bgp vpnv4 rd 1100:1001 10.30.116.0/23
BGP routing table entry for 1100:1001:10.30.116.0/23, version 26765275
Paths: (9 available, best #6, no table)
  Advertised to update-groups:
     1          2          3         
  (65001 64955 65003) 65089, (Received from a RR-client)
    172.16.254.226 (metric 20645) from 172.16.224.236 (172.16.224.236)
      Origin IGP, metric 0, localpref 100, valid, confed-internal
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/362
  (65008 64955 65003) 65089
    172.16.254.226 (metric 20645) from 10.131.123.71 (10.131.123.71)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/362
  (65001 64955 65003) 65089
    172.16.254.226 (metric 20645) from 172.16.216.253 (172.16.216.253)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/362
  (65001 64955 65003) 65089
    172.16.254.226 (metric 20645) from 172.16.216.252 (172.16.216.252)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/362
  (64955 65003) 65089
    172.16.254.226 (metric 20645) from 10.77.255.57 (10.77.255.57)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/362
  (64955 65003) 65089
    172.16.254.226 (metric 20645) from 10.57.255.11 (10.57.255.11)
      Origin IGP, metric 0, localpref 100, valid, confed-external, best
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/362

!--- BGP selects this as the Best Path on comparing 
!--- with all the other routes and selected based on lower router ID.

  (64955 65003) 65089
    172.16.254.226 (metric 20645) from 172.16.224.253 (172.16.224.253)
      Origin IGP, metric 0, localpref 100, valid, confed-internal
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/362
  (65003) 65089
    172.16.254.226 (metric 20645) from 172.16.254.234 (172.16.254.234)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/362
  65089, (Received from a RR-client)
    172.16.228.226 (metric 20645) from 172.16.228.226 (172.16.228.226)
      Origin IGP, metric 0, localpref 100, valid, confed-internal
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/278

O BGP seleciona o melhor caminho desses 9 caminhos, considerando vários atributos explicados neste documento. Na saída mostrada aqui, o BGP compara os caminhos disponíveis e seleciona o caminho 6 como o melhor caminho com base na router-ID mais baixa.

Comparing path 1 with path 2:
	Both paths have reachable next hops
	Both paths have a WEIGHT of 0
	Both paths have a LOCAL_PREF of 100
	Both paths are learned
	Both paths have AS_PATH length 1
	Both paths are of origin IGP
	The paths have different neighbor AS's so ignoring MED
	Both paths are internal
	  (no distinction is made between confed-internal and confed-external)
	Both paths have an IGP metric to the NEXT_HOP of 20645
Path 2 is better than path 1 because it has a lower Router-ID.

Comparing path 2 with path 3:
	Both paths have reachable next hops
	Both paths have a WEIGHT of 0
	Both paths have a LOCAL_PREF of 100
	Both paths are learned
	Both paths have AS_PATH length 1
	Both paths are of origin IGP
	Both paths have the same neighbor AS, 65089, so comparing MED.
	Both paths have a MED of 0
	Both paths are confed-external
	Both paths have an IGP metric to the NEXT_HOP of 20645
Path 2 is better than path 3 because it has a lower Router-ID.

Comparing path 2 with path 4:
	Both paths have reachable next hops
	Both paths have a WEIGHT of 0
	Both paths have a LOCAL_PREF of 100
	Both paths are learned
	Both paths have AS_PATH length 1
	Both paths are of origin IGP
	Both paths have the same neighbor AS, 65089, so comparing MED.
	Both paths have a MED of 0
	Both paths are confed-external
	Both paths have an IGP metric to the NEXT_HOP of 20645
Path 2 is better than path 4 because it has a lower Router-ID.

Comparing path 2 with path 5:
	Both paths have reachable next hops
	Both paths have a WEIGHT of 0
	Both paths have a LOCAL_PREF of 100
	Both paths are learned
	Both paths have AS_PATH length 1
	Both paths are of origin IGP
	Both paths have the same neighbor AS, 65089, so comparing MED.
	Both paths have a MED of 0
	Both paths are confed-external
	Both paths have an IGP metric to the NEXT_HOP of 20645
Path 5 is better than path 2 because it has a lower Router-ID.

Comparing path 5 with path 6:
	Both paths have reachable next hops
	Both paths have a WEIGHT of 0
	Both paths have a LOCAL_PREF of 100
	Both paths are learned
	Both paths have AS_PATH length 1
	Both paths are of origin IGP
	Both paths have the same neighbor AS, 65089, so comparing MED.
	Both paths have a MED of 0
	Both paths are confed-external
	Both paths have an IGP metric to the NEXT_HOP of 20645
Path 6 is better than path 5 because it has a lower Router-ID.

Comparing path 6 with path 7:
	Both paths have reachable next hops
	Both paths have a WEIGHT of 0
	Both paths have a LOCAL_PREF of 100
	Both paths are learned
	Both paths have AS_PATH length 1
	Both paths are of origin IGP
	Both paths have the same neighbor AS, 65089, so comparing MED.
	Both paths have a MED of 0
	Both paths are internal
	  (no distinction is made between confed-internal and confed-external)
	Both paths have an IGP metric to the NEXT_HOP of 20645
Path 6 is better than path 7 because it has a lower Router-ID.

Comparing path 6 with path 8:
	Both paths have reachable next hops
	Both paths have a WEIGHT of 0
	Both paths have a LOCAL_PREF of 100
	Both paths are learned
	Both paths have AS_PATH length 1
	Both paths are of origin IGP
	Both paths have the same neighbor AS, 65089, so comparing MED.
	Both paths have a MED of 0
	Both paths are confed-external
	Both paths have an IGP metric to the NEXT_HOP of 20645
Path 6 is better than path 8 because it has a lower Router-ID.

Comparing path 6 with path 9:
	Both paths have reachable next hops
	Both paths have a WEIGHT of 0
	Both paths have a LOCAL_PREF of 100
	Both paths are learned
	Both paths have AS_PATH length 1
	Both paths are of origin IGP
	The paths have different neighbor AS's so ignoring MED
	Both paths are internal
	  (no distinction is made between confed-internal and confed-external)
	Both paths have an IGP metric to the NEXT_HOP of 20645
Path 6 is better than path 9 because it has a lower Router-ID.
The best path is #6

Personalize o processo de seleção do caminho

O atributo da comunidade estendida, que é chamada a comunidade de custo BGP, fornece uma maneira de personalizar o processo de seleção do melhor caminho. Uma etapa adicional, em que as comunidades do custo são comparadas, é adicionada ao algoritmo que como o algoritmo do melhor caminho trabalha a seção descreve. Esta etapa vem após o passo requerido (ponto da inserção) no algoritmo. O trajeto com o valor o mais barato é preferido. 

Note: Esteja ciente destes artigos:

-Esta etapa é saltada se você emitiu o comando bgp bestpath cost-community ignore.

- A cláusula do conjunto de comunidade de custo é configurada com um número de ID da comunidade de custo (0 a 255) e um valor de número de custo (0 a 4.294.967.295). O valor numérico do custo determina a preferência para o trajeto. O trajeto com o valor numérico mais barato é preferido. Os caminhos que não são configurados especificamente com o valor do número de custo recebem um valor de número de custo padrão de 2.147.483.647. Esse valor é o ponto médio entre 0 e 4.294.967.295. Esses caminhos são avaliados de acordo com o processo de seleção do melhor caminho. Se dois trajetos são configurados com o mesmo valor numérico do custo, o processo de seleção do caminho prefere o trajeto com a mais baixa comunidade ID. Se os trajetos têm um custo de pre-bestpath cost community, o trajeto com pre-bestpath cost community mais baixo é selecionado como o melhor caminho.

- ABSOLUTE_VALUE é a primeira etapa para determinar o grau de preferência de um caminho. Por exemplo, quando o EIGRP é redistribuído ao VPNv4 BGP, o tipo ABSOLUTE_VALUE é usado para a comunidade do custo. O IGB_Cost está considerado depois que a distância (IGP) interior ao salto seguinte foi comparada. Isto significa que as comunidades do custo com o ponto IGP_COST da inserção estão consideradas após etapa 8 do algoritmo em como o algoritmo do melhor caminho trabalha.

Multipath de BGP

O multipath de BGP permite a instalação na tabela de IP Routing de trajetos múltiplos BGP ao mesmo destino. Estes trajetos são instalados na tabela junto com o melhor caminho para o compartilhamento de carga. O multipath de BGP não afeta a seleção de melhor caminho. Por exemplo, um roteador ainda designa um dos caminhos como o melhor caminho, de acordo com o algoritmo, e anuncia esse melhor caminho para os vizinhos.

Estas são as características do multipath de BGP:

• eBGP Multipath - maximum-paths n

• Multicaminho iBGP - caminhos máximos ibgp n

• eiBGP Multipath - EBGP de caminhos máximos

A fim serem candidatos para multipath, trajetos à mesma necessidade do destino de ter estas características iguais às características do melhor caminho:

• Peso

• Preferência local

• Comprimento AS-PATH

• Origem

• MED

• Um destes:

  • Vizinho COMO ou secundário-COMO (antes da adição da característica Multipath do eiBGP)

  • AS-PATH (após a adição da característica Multipath do eiBGP)

Algumas características do multipath de BGP puseram exigências adicionais sobre candidatos de multipath.

Estes são os requisitos de multicaminho eBGP adicionais:

• O caminho deve ser aprendido com um vizinho externo ou confederation-external (eBGP).

• A métrica de IGP para o próximo salto de BGP deve ser igual à métrica de IGP best-path.

Estas são as exigências adicionais para multicaminhos iBGP:

• O caminho deve ser aprendido com um vizinho interno (iBGP).

• A métrica de IGP para o próximo salto de BGP deve ser igual à métrica de IGP best-path, a menos que o roteador esteja configurado para multipath iBGP unequal-cost.

O BGP introduz até caminhos recebidos n recentemente dos candidatos de multipath na tabela de IP Routing. O valor máximo de n varia de acordo com a plataforma e a versão do software. Plataformas mais antigas podem suportar apenas 6 caminhos, enquanto plataformas modernas podem suportar 16, 32 ou mais. O valor padrão, quando multipath está desabilitado, é 1.

Para o balanço de carga de custo desigual, você pode usar a largura de banda de enlace BGP. 

Note: O seguinte-salto-auto equivalente é executado no melhor caminho que está selecionado entre multipath de eBGP antes que esteja enviado aos peers internos.

Informações Relacionadas

• Troubleshooting de BGP
• Como os roteadores BGP usam o Multi-Exit Discriminator para a seleção do melhor caminho
• Configurando o BGP
• Página de suporte de BGP
• Suporte Técnico e Documentação - Cisco Systems

Histórico de revisões

Revisão	Data de publicação	Comentários
6.0	28-Apr-2026	Formatação
5.0	02-Dec-2024	Formatação e links fixos.
4.0	11-Jul-2023	Título, introdução e formatação atualizados. Informações de fundo adicionadas.
3.0	22-Jun-2022	Atualizado para diretrizes de tradução automática.
1.0	10-Dec-2001	Versão inicial