Use o MultiExit Discriminator para influenciar a seleção do melhor caminho do BGP
Introdução
Este documento descreve o comando bgp deterministic-med e como ele afeta a seleção de caminho com base no discriminador de multisaída (MED).
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Roteamento IP básico
- Protocolo de gateway de borda (BGP)
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 rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Conventions
Para obter mais informações sobre convenções de documentação da Cisco, consulte Convenções de Dicas Técnicas da Cisco.
O Atributo MED
O MED é um atributo BGP opcional, não transitivo, que fornece uma dica aos vizinhos externos sobre o caminho preferido em um sistema autônomo (AS) com vários pontos de entrada. A MED também é conhecida como a métrica externa de uma rota e um valor MED mais baixo tem preferência sobre um valor mais alto. Por padrão, o BGP compara os valores MED somente entre os caminhos recebidos do mesmo AS vizinho.
Note: Por padrão, o BGP compara valores MED somente para caminhos recebidos do mesmo AS vizinho, a menos que o bgp always-compare-med esteja configurado. Consulte Como o Comando bgp deterministic-med difere do Comando bgp always-compare-med para obter informações adicionais.
Topologia de rede
Topologia de rede
Exemplo
Neste cenário, o AS 65502 é um usuário do ISP que tem o AS 65501. O R4 está conectado a dois roteadores diferentes no lado do ISP para fins de redundância e anuncia duas redes ao ISP—10.4.0.0/16 e 10.5.0.0/16. Algumas das configurações relevantes são mostradas nesta seção.
| R4 |
|---|
! hostname r4 ! ip cef ! ! interface Loopback10 ip address 10.4.0.1 255.255.0.0 ! interface Loopback11 ip address 10.5.0.1 255.255.0.0 ! interface Serial0/0 ip address 192.168.20.4 255.255.255.0 ! interface Serial1/0 ip address 192.168.30.4 255.255.255.0 ! router bgp 65502 no synchronization bgp log-neighbor-changes network 10.4.0.0 mask 255.255.0.0 network 10.5.0.0 mask 255.255.0.0 neighbor 192.168.20.2 remote-as 65501 neighbor 192.168.30.3 remote-as 65501 no auto-summary ! ip classless ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 exec-timeout 0 0 login ! ! end |
| R2 |
|---|
! hostname r2 ! ip cef ! ! interface Loopback0 ip address 10.2.2.2 255.255.255.255 ! interface Ethernet0/0 ip address 172.16.0.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 serial restart-delay 0 ! interface Serial2/0 ip address 192.168.20.2 255.255.255.0 serial restart-delay 0 ! router ospf 1 log-adjacency-changes redistribute connected passive-interface Serial2/0 network 10.2.2.2 0.0.0.0 area 0 network 172.16.0.2 0.0.0.0 area 0 network 192.168.1.2 0.0.0.0 area 0 network 192.168.20.2 0.0.0.0 area 0 ! router bgp 65501 no synchronization bgp log-neighbor-changes neighbor 10.1.1.1 remote-as 65501 neighbor 10.1.1.1 update-source Loopback0 neighbor 10.3.3.3 remote-as 65501 neighbor 10.3.3.3 update-source Loopback0 neighbor 192.168.20.4 remote-as 65502 no auto-summary ! ip classless ! ! line con 0 exec-timeout 0 0 transport preferred all transport output all line aux 0 transport preferred all transport output all line vty 0 4 exec-timeout 0 0 login transport preferred all transport input all transport output all ! end |
As configurações relevantes de R1 e R3 usam o mesmo design de R2. R1, R2 e R3 têm alcance de iBGP através de interfaces de loopback e o IGP fornece acessibilidade aos próximos saltos de BGP. R3 tem uma sessão eBGP com sessões R4 e iBGP com R1 e R2.
R1 tem um iBGP que corresponde a R2 e um a R3. Observe o que as tabelas de BGP de R1, R2 e R3 exibem para as duas redes anunciadas por R4:
r2#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 7
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.3.3.3
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
65502
192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
r2#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 6
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.3.3.3
65502
192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
r3#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 8
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.2.2.2
65502
192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.30.4 from 192.168.30.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
r3#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.2.2.2
65502
192.168.30.4 from 192.168.30.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
65502
192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
r1#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65502
192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
65502
192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
r1#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
65502
192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
R2 e R3 escolhem o melhor caminho como a rota externa de R4, o que é esperado com base no algoritmo de seleção de melhor caminho BGP. Consulte o algoritmo de seleção de melhor caminho BGP para obter mais informações.
Da mesma forma, R1 escolhe R2 para acessar as duas redes porque o vínculo anterior dos atributos do melhor caminho do BGP, e o menor ID do roteador do BGP é usado como o desempate. R2 tem o ID do roteador 10.2.2.2 e R3 tem o ID do roteador 10.3.3.3. Como o ID do roteador R2s é 10.2.2.2 e o ID do roteador R3s é 10.3.3.3, R2 é escolhido. Nessa configuração básica, todo o tráfego para as duas redes no AS 65502 passa de R1 a R2 e depois para R4 por padrão. Agora, suponha que R4 deseja balancear a carga do tráfego que recebe do AS 65501. Para fazer isso sem nenhuma modificação de ISP R4, você configura R4 para utilizar o MED para forçar o tráfego de uma rede para um caminho abaixo e o tráfego da outra rede para o outro caminho.
Note: Observe que o exemplo de configuração MED descrito fornece uma engenharia de tráfego por prefixo, não um balanceamento de carga de custo igual real.
Esta é a configuração de R4 depois que você aplica a configuração necessária:
| R4 |
|---|
! hostname r4 ! ip cef ! ! ! interface Loopback10 ip address 10.4.0.1 255.255.0.0 ! interface Loopback11 ip address 10.5.0.1 255.255.0.0 ! interface Serial0/0 ip address 192.168.20.4 255.255.255.0 ! interface Serial1/0 ip address 192.168.30.4 255.255.255.0 ! router bgp 65502 no synchronization bgp log-neighbor-changes network 10.4.0.0 mask 255.255.0.0 network 10.5.0.0 mask 255.255.0.0 neighbor 192.168.20.2 remote-as 65501 neighbor 192.168.20.2 route-map setMED-R2 out neighbor 192.168.30.3 remote-as 65501 neighbor 192.168.30.3 route-map setMED-R3 out no auto-summary ! ip classless no ip http server ! ! access-list 1 permit 10.4.0.0 0.0.255.255 access-list 2 permit 10.5.0.0 0.0.255.255 ! route-map setMED-R3 permit 10 match ip address 1 set metric 200 ! route-map setMED-R3 permit 20 match ip address 2 set metric 100 !--- The route-map setMED-R3 is applying a MED of 200 to the 10.4.0.0/16 |
Observação: neste exemplo, somente 10.4.0.0/16 e 10.5.0.0/16 são anunciados. Se prefixos adicionais forem anunciados ao mesmo vizinho, adicione-os à lista de acesso ou sequência de mapa de rota apropriada. Adicione uma sequência de permissão final se prefixos sem correspondência precisarem ser anunciados sem serem filtrados pelo mapa de rota de saída.
Após a aplicação do MED, R2 seleciona o caminho/link R2-para-R4 como melhor para 10.4.0.0/16, e R3 seleciona o caminho/link R3-para-R4 como melhor para 10.5.0.0/16. No estado convergido mostrado, R1 recebe o melhor anúncio iBGP qualificado para cada prefixo e usa R2 para 10.4.0.0/16 e R3 para 10.5.0.0/16:
r1#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 14
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
Not advertised to any peer
65502
192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
r1#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 13
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
Not advertised to any peer
65502
192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 100, localpref 100, valid, internal, best
Consulte o próximo exemplo para a exibição de R2:
r2#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 10
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.3.3.3
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 100, localpref 100, valid, external, best
r2#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.20.4
65502
192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 100, localpref 100, valid, internal, best
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 200, localpref 100, valid, external
R2 mostra um caminho para 10.4.0.0/16 porque R3 não anuncia mais seu caminho aprendido por R4 depois que R3 seleciona o caminho aprendido por iBGP através de R2 como melhor. O R3 retira a atualização (envia uma retirada de rota BGP, esta atualização contém uma métrica inalcançável) para 10.4.0.0/16 uma vez que percebe que R3 usa R2 para acessar 10.4.0.0/16. As regras de anúncio padrão do iBGP impedem que R3 anuncie o caminho aprendido do iBGP de volta para outro peer iBGP nesta topologia:
r3#show ip bgp 10.4.0.0
BGP routing table entry for 10.4.0.0/16, version 20
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.30.4
65502
192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
65502
192.168.30.4 from 192.168.30.4 (10.4.4.4)
Origin IGP, metric 200, localpref 100, valid, external
Isso permite que R2 salve alguma memória, pois não precisa armazenar essas informações inúteis. Caso a sessão BGP entre R2 e R4 falhe, R2 enviaria uma atualização inalcançável para R3 para 10.4.0.0/16. Essa atualização acionaria R3 para enviar uma atualização com a rota de R3 para 10.4.0.0/16 através de R4 para R2. R2 pode começar a rotear através de R3.
O comando MED
Para habilitar a comparação determinística de MED, configure o comando bgp deterministic-med no modo de configuração do roteador BGP. Quando habilitado, o bgp deterministic-med remove a dependência temporal das decisões de melhor caminho baseadas em MED agrupando caminhos do mesmo AS antes da comparação. Isso garante que uma comparação MED precisa seja feita em todas as rotas recebidas do mesmo sistema autônomo (AS).
Se você desabilitar o bgp deterministic-med, as rotas de ordem recebidas poderão afetar as decisões de melhor caminho baseadas no MED. Isso pode ocorrer quando a mesma rota é recebida de vários ASs ou sub-ASs de confederação, com exatamente o mesmo comprimento de caminho, mas MEDs diferentes.
Examples
Por exemplo, considere as próximas rotas:
| Entrada | Caminho AS | MED | Preferência local | Comprimento do Caminho AS | Origem |
|---|---|---|---|---|---|
| entrada1 |
AS 65001 |
100 |
100 |
1 |
IGP |
| entrada2 |
AS 65002 |
50 |
100 |
1 |
IGP |
| entrada3 |
AS 65001 |
20 |
100 |
1 |
IGP |
Um roteador BGP com MED desabilitado
Exemplo de Ordem de Chegada 1
A ordem em que as rotas BGP foram recebidas é (entry1 é a entrada mais antiga na tabela BGP e entry3 é a mais nova):
- entrada1
- entrada2
- entrada3
Inicialmente, existe apenas uma rota, portanto, entry1 se torna o melhor caminho. Quando a entrada2 do AS65002 é comparada com a entrada1 do AS65001, a MED é ignorada porque as rotas vêm de ASs vizinhos diferentes; como todos os atributos restantes são iguais, o roteador mantém o melhor caminho atual, entry1.
Quando a entrada 3 de AS65001 com MED 20 é comparada com a entrada 1 de AS65001 com MED 100, a MED é avaliada porque ambas as rotas vêm do mesmo AS vizinho. Como 20 é inferior a 100, a entrada3 se torna o melhor caminho final.
Exemplo de Ordem de Chegada 2
Agora, suponha que as mesmas rotas cheguem em uma ordem diferente:
- entrada2
- entrada3
- entrada1
Inicialmente, a entrada 2 é selecionada como o melhor caminho. Quando a entrada3 de AS65001 é comparada com a entrada2 de AS65002, a MED não é avaliada porque as rotas vêm de ASs vizinhos diferentes; como todos os atributos restantes são iguais, o roteador mantém o melhor caminho atual, entry2.
Quando a entrada1 do AS65001 é comparada com a entrada2 do AS65002, o MED é novamente ignorado porque as rotas vêm de ASs vizinhos diferentes. Como resultado, o roteador mantém a entrada 2 como o melhor caminho final.
Com o MED desativado, a ordem de chegada da rota influencia a sequência de comparação. Observe que o roteador recebido é exatamente as mesmas três rotas, ainda que tenha selecionado melhores caminhos diferentes porque as rotas chegaram em uma ordem diferente. Essa é a dependência temporal que o bgp deterministic-med foi projetado para eliminar.
Note: Para obter mais informações sobre critérios de seleção de caminho BGP, consulte Algoritmo de seleção de melhor caminho BGP.
Um roteador BGP com MED habilitado
Com o MED ativado, o roteador primeiro agrupa as rotas pelo AS vizinho antes de tomar qualquer decisão baseada no MED. Nesse caso, as rotas do mesmo AS são agrupadas e as melhores entradas de cada grupo são comparadas. No exemplo dado, há dois ASs, AS 65001 e AS 65002.
| Grupo | Caminho AS | Entrada | Rota selecionada | Razão |
|---|---|---|---|---|
| Grupo 1 |
AS 65001 |
entrada1 (DEM 100), entrada3 (DEM 20) |
entrada3 |
DEM inferior (20 < 100) |
| Grupo 2 |
AS 65002 |
entrada 2 (DEM 50) |
entrada2 |
Somente candidato |
No Grupo 1, o melhor caminho é a entrada 3 devido ao MED inferior (o MED é usado nesta decisão, já que os caminhos são do mesmo AS). No Grupo 2, há apenas uma entrada (entrada2). O melhor caminho então é determinado com uma comparação dos vencedores de cada grupo, MED não é usado nesta comparação por padrão porque os vencedores de cada grupo são de AS diferentes.
Neste ponto, o MED não é mais considerado, porque as rotas restantes se originam de ASs vizinhos diferentes. O algoritmo de melhor caminho BGP continua com os atributos subsequentes (como eBGP vs. iBGP, métrica IGP para o próximo salto, caminho mais antigo, ID do roteador e assim por diante, dependendo de quais atributos diferem).
A principal vantagem é que esse processo é independente das rotas recebidas. Se o roteador aprende as rotas como:
- entry1 → entry2 → entry3
- entry2 → entry3 → entry1
- entry3 → entry1 → entry2
Como resultado, as ordens de chegada produzem o mesmo resultado porque a decisão é baseada nos atributos da rota em vez da ordem em que as atualizações foram recebidas.
Note: Se o bgp always-compare-med também foi habilitado quando você compara o entry3 (o vencedor do Grupo 1) e o entry 2 (o vencedor do Grupo 2); a entrada 3 é a vencedora por causa do MED inferior.
Note: Ativar o comando bgp deterministic-med garante a comparação da variável MED ao escolher rotas anunciadas por diferentes peers no mesmo AS. Ativar o comando bgp always-compare-med garante a comparação do MED para caminhos de vizinhos em AS diferentes.
Este exemplo pressupõe que todos os atributos BGP de prioridade mais alta (como Peso, Preferência local, Comprimento do caminho AS, Origem e outros) são idênticos. A finalidade é isolar o efeito do MED e ilustrar por que desativar o bgp deterministic-med pode garantir que a decisão do melhor caminho depende da ordem de chegada da rota.
A Cisco recomenda que você habilite o bgp always-compare-med em todas as novas implantações de rede. Além disso, se o bgp always-compare-med estiver habilitado, as decisões do BGP MED são sempre determinísticas.
Para obter mais informações sobre os comandos bgp deterministic-med e bgp always-compare-med, consulte Como o Comando bgp deterministic-med Difere do Comando bgp always-compare-med.
Informações Relacionadas
- Configuração de exemplo para o BGP com dois provedores de serviço diferentes (multilocal)
- Suporte IP/BGP
- Estudos de caso de BGP
- Suporte técnico e downloads da Cisco
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
3.0 |
30-Jul-2026
|
Título, introdução, ortografia, gramática e inserção de linhas horizontais atualizados em seções separadas/legibilidade. |
2.0 |
26-Jan-2024
|
Otimização de mecanismo de pesquisa e formatação atualizada. |
1.0 |
10-Dec-2001
|
Versão inicial |
Feedback