Este documento descreve a função do algoritmo do melhor caminho BGP (Border Gateway Protocol). 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 BGP estiver habilitada, deve haver uma correspondência para o prefixo na tabela de roteamento IP para que um caminho BGP interno (iBGP) seja 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.
Nota: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.
Tais trajetos são negados em cima do ingresso no roteador e nem sequer instalados na base da informação de roteamento de BGP (RIB). 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 marcados como (somente recebidos) 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.
Note: O PESO é um parâmetro específico da Cisco. É local ao roteador em que é configurado.
Prefira o trajeto com o LOCAL_PREF mais alto.
Note: 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.
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 AIGP para BGP para obter mais detalhes.
Prefira o trajeto com o AS_PATH mais curto.
Note: Esteja ciente destes artigos:
- 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.
Note: O IGP é mais baixo do que o Protocolo de Gateway Exterior (EGP), e o EGP é mais baixo do que INCOMPLETO.
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 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ê habilitou bgp bestpath med missing-as-worst, os caminhos recebem um MED de 4.294.967.294.
Se você habilitou bgp bestpath med missing-as-worstOs 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).
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.
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.
Note: Os Cisco IOS Software Release 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 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.
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.
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.
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. A 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 Path# 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.
Note: Esteja ciente destes artigos:
- 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 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.
- 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 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 o multipath está desativado, é 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.