O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve a função do algoritmo de melhor caminho do Border Gateway Protocol (BGP).
Os roteadores BGP geralmente 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.
Supor que todos os trajetos que um roteador recebe para um prefixo particular estão arranjados em uma lista. A lista é semelhante à saída do comando show ip bgp longer-prefixes
comando. Neste caso, alguns trajetos não são considerados como candidatos para o melhor caminho. Esses caminhos normalmente não têm o sinalizador válido na saída do comando show ip bgp longer-prefixes
comando. Os roteadores ignoram trajetos nestas circunstâncias:
Caminhos marcados como não sincronizados no show ip bgp longer-prefixes
saída.
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. A sincronização de BGP é permitida à revelia no software de Cisco IOS®. Se a rota correspondente for aprendida de um vizinho OSPF (Open Shortest Path First), seu ID de roteador OSPF deve corresponder ao ID de roteador BGP do vizinho iBGP. A maioria dos usuários prefere desativar a sincronização com o uso do comando no synchronization
Subcomando BGP.
Observação: 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 no ingresso no roteador e nem mesmo são instalados na Base de Informações de Roteamento (RIB - Routing Information Base) BGP. O mesmo se aplica a qualquer caminho que seja negado por uma política de roteamento implementada através de 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 o 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 que são marcados como (somente recebimento) no show ip bgp longer-prefixes
saída
A política rejeitou estes trajetos. No entanto, o roteador armazenou os caminhos porque você configurou soft-reconfiguration inbound
para o vizinho que envia o 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 que são usadas para determinar o melhor caminho:
Prefira o trajeto com o PESO o mais alto.
Observação: WEIGHT é um parâmetro específico da Cisco. É local ao roteador em que é configurado.
Prefira o trajeto com o LOCAL_PREF mais alto.
Observação: um caminho sem LOCAL_PREF é considerado como tendo o valor definido com o bgp default local-preference
ou para ter um valor de 100 por padrão.
Preferem o caminho que foi originado localmente por meio de um network
or aggregate
Subcomando BGP ou através de redistribuição de um IGP.
Caminhos locais originados pelo network
or redistribute
são preferidos em relação às agregações locais originadas pelo aggregate-address
comando.
Observação: 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 AIGP para BGP para obter mais detalhes.
Prefira o trajeto com o AS_PATH mais curto.
Observação: esteja ciente destes itens:
- Esta etapa será ignorada se você tiver configurado o bgp bestpath as-path ignore
comando.
-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.
Prefira o trajeto com o mais baixo tipo da origem.
Observação: o IGP é inferior ao Exterior Gateway Protocol (EGP) e o EGP é inferior ao INCOMPLETE.
Prefira o trajeto com o mais baixo Multi-Exit Discriminator (MED).
Observação: esteja ciente destes itens:
-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 será ignorado.
- Se bgp always-compare-med
estiver ativado, os MEDs serão comparados para todos os caminhos.
Você deve desabilitar esta opção sobre o todo o AS. Se não, os loop de roteamento podem ocorrer.
- Se bgp bestpath med-confed
estiver ativado, os MEDs serão comparados para todos os caminhos que consistem apenas em 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.
O MED dos caminhos que são recebidos de um vizinho com um MED de 4.294.967.295 são considerados válidos e são inseridos na tabela BGP com efeito para os Códigos corrigidos para o bug da Cisco ID CSCef34800.
- Os caminhos recebidos sem MED recebem um MED de 0, a menos que você tenha ativado bgp bestpath med missing-as-worst
.
Se você tiver habilitado bgp bestpath med missing-as-worst
, os caminhos recebem um MED de 4.294.967.294.
Se você tiver habilitado bgp bestpath med missing-as-worst
Os caminhos recebem um MED de 4.294.967.295 com efeito para os códigos corrigidos para o bug da Cisco ID CSCef34800.
-O bgp deterministic-med
também pode influenciar essa etapa.
Refira a como os BGP Router usam o Multi-Exit Discriminator para a seleção do melhor caminho para uma demonstração.
Prefira o eBGP sobre trajetos do iBGP.
Se o melhor caminho é selecionado, vá para Passo 9 (multipath).
Observação: os caminhos que contêm AS_CONFED_SEQUENCE e AS_CONFED_SET são locais para a 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.
Prefira o trajeto com o mais baixo IGP métrico ao salto seguinte BGP.
Continue, mesmo se o melhor caminho é selecionado já.
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.
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ê habilitou o bgp best path compare-routerid
comando.
Observação: o 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 introduziu esse 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.
Prefira a rota que vem do Roteador BGP com a mais baixa identificação do roteador
O Router ID é o endereço IP mais alto no roteador, com a preferência dada aos endereços de loopback. Além disso, você pode usar o comando bgp router-id
para definir manualmente o ID do roteador.
Observação: se um caminho contiver atributos de refletor de rota (RR), o ID do originador será substituído pelo ID do roteador no processo de seleção de caminho.
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.
Prefira o trajeto que vem do mais baixo endereço vizinho.
Esse endereço é o endereço IP usado no BGP neighbor
configuração. O endereço corresponde ao peer remoto que é usado na conexão de TCP com o roteador local.
Neste exemplo, 9 caminhos estão disponíveis para a rede 10.30.116.0/23. O 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 entre esses 9 caminhos através da consideração de vários atributos que são 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 em seu ID de roteador mais baixo.
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
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.
Observação: esteja ciente destes itens:
- Esta etapa será ignorada se você tiver emitido o bgp bestpath cost-community ignore
comando.
- A cláusula cost community set é configurada com um número de ID de comunidade de custo (0 a 255) e 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 trajetos que não são configurados especificamente com o valor numérico do custo são atribuídos um valor numérico dos custos padrão de 2.147.483.647. Este valor é o ponto médio entre 0 e 4.294.967.295. Estes trajetos são avaliados então em conformidade pelo 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.
- O ABSOLUTE_VALUE é considerado 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.
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 seus vizinhos.
Estas são as características do multipath de BGP:
Multipath de eBGP - maximum-paths n
Multicaminho iBGP - maximum-paths ibgp n
multicaminho eiBGP - maximum-paths eibgp
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 de um vizinho externo ou externo à confederação (eBGP).
A métrica IGP para o próximo salto de BGP deve ser igual à métrica IGP de melhor caminho.
Estas são as exigências adicionais para multicaminhos iBGP:
O caminho deve ser aprendido de um vizinho interno (iBGP).
A métrica IGP para o próximo salto de BGP deve ser igual à métrica IGP de melhor caminho, a menos que o roteador esteja configurado para multicaminho iBGP de custo desigual.
O BGP introduz até caminhos recebidos n recentemente dos candidatos de multipath na tabela de IP Routing. O valor máximo de n é atualmente 6. 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.
Observação: o next-hop-self equivalente é executado no melhor caminho selecionado entre os multicaminhos eBGP antes de ser encaminhado aos peers internos.
Revisão | Data de publicação | Comentários |
---|---|---|
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 |