Como os roteadores BGP usam o Multi-Exit Discriminator para a seleção do melhor caminho
Índice
Introdução
Este documento demonstra o uso do comando bgp deterministic-med e explica como ele pode efetuar a seleção de caminho com base no Multi-Exit Discriminator (MED).
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 você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.
Convenções
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
O atributo MED
O MED é um atributo nontransitive opcional. O MED é uma sugestão aos vizinhos externos sobre o caminho preferido em um sistema autônomo que tem pontos de entrada múltipla. O MED é sabido igualmente como a métrica externo de uma rota. Um valor med mais baixo é preferido sobre um valor mais alto.
Esta seção descreve um exemplo de como usar o MED para influenciar a decisão de roteamento tomada por um vizinho COMO.
Topologia: 
Exemplo
Nesta encenação, COMO 65502 é um cliente do ISP que tem COMO 65501. O R4 é conectado a dois Roteadores diferentes no lado ISP para fins de redundância e anuncia duas redes ao ISP — 10.4.0.0/16 e 10.5.0.0/16. Alguma da configuração relevante é mostrada nesta seção.
| R4 |
|---|
! version 12.3 ! 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 |
|---|
! version 12.3 ! hostname r2 ! ip cef ! ! interface Loopback0 ip address 2.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 2.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 1.1.1.1 remote-as 65501 neighbor 1.1.1.1 update-source Loopback0 neighbor 3.3.3.3 remote-as 65501 neighbor 3.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 do r1 e do R3 são similares ao R2. O R3 tem um eBGP que espreite com R4 e um iBGP que espreita com r1.
O r1 tem um iBGP que espreita ao R2 e a um ao R3. Deixe-nos olhar o que o r1, as tabelas de BGP R2, e R3 indicam para as duas redes anunciadas pelo 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:
1.1.1.1 3.3.3.3
65502
192.168.20.4 from 192.168.20.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
65502
192.168.30.4 (metric 74) from 3.3.3.3 (3.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:
1.1.1.1 3.3.3.3
65502
192.168.30.4 (metric 74) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.20.4 from 192.168.20.4 (4.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:
1.1.1.1 2.2.2.2
65502
192.168.20.4 (metric 74) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.30.4 from 192.168.30.4 (4.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:
1.1.1.1 2.2.2.2
65502
192.168.30.4 from 192.168.30.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
65502
192.168.20.4 (metric 74) from 2.2.2.2 (2.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 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
65502
192.168.30.4 (metric 128) from 3.3.3.3 (3.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 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.20.4 (metric 128) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Como nós podemos ver, o R2 e o R3 escolhem enquanto melhor caminho a rota externa do R4 que está esperado que concorda o algoritmo de seleção do melhor caminho BGP. Consulte o algoritmo de seleção de melhor caminho BGP para obter mais informações.
Similarmente, os choses R2 do r1 para alcançar as 2 redes, que são de acordo com a regra do melhor caminho BGP — selecionam o trajeto com o mais baixo Router ID, em iguais circunstâncias. Porque o Router ID R2 é 2.2.2.2 e o Router ID R3 é 3.3.3.3, o R2 é escolhido. Nesta configuração básica todo o tráfego às duas redes dentro COMO 65502 passagens do r1 com o R2 e então ao R4 à revelia. Supõe agora que o R4 quer carregar o equilíbrio o tráfego que recebe COMO de 65501. Para fazer assim sem pedir o R4 ISP para fazer todas as alterações, você pode configurar o R4 para utilizar o MED para forçar o tráfego para uma rede abaixo de um trajeto, e o tráfego para a outra rede abaixo do outro trajeto.
Este é que a configuração do R4 depois que nós aplicamos a configuração necessária:
| R4 |
|---|
! version 12.3 ! 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 MED-R3 is applying a MED of 200 to the 10.4.0.0/16 !--- network and a MED of 100 to the 10.5.0.0/16 network. !--- The route-map is being applied outbound towards R3. ! route-map setMED-R2 permit 10 match ip address 1 set metric 100 ! route-map setMED-R2 permit 20 match ip address 2 set metric 200 !--- The route-map MED-R2 is applying a MED of 100 to the 10.4.0.0/16 !--- network and a MED of 200 to the 10.5.0.0/16 network. !--- The route-map is being applied outbound towards R2. ! ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 exec-timeout 0 0 login ! ! end |
Nota: Você precisa de cancelar a sessão de BGP com o comando clear ip bgp * soft out, por exemplo, fazer estes a configuração tomar a ação.
O r1 vê agora a rota sobre o R2 como o melhor caminho para a rede 10.4.0.0/16 porque a atualização recebida do R2 tem um MED de 100 contra um MED de 200, que seja o que o R3 anuncia. Similarmente, os usos R3 do r1 e o R3- R4 ligam para alcançar 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 2.2.2.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
r1#sh 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 3.3.3.3 (3.3.3.3)
Origin IGP, metric 100, localpref 100, valid, internal, best
Deixe-nos olhar o indicador 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:
1.1.1.1 3.3.3.3
65502
192.168.20.4 from 192.168.20.4 (4.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 3.3.3.3 (3.3.3.3)
Origin IGP, metric 100, localpref 100, valid, internal, best
65502
192.168.20.4 from 192.168.20.4 (4.4.4.4)
Origin IGP, metric 200, localpref 100, valid, external
A razão pela qual o R2 mostra somente um trajeto para 10.4.0.0/16 é porque o R3 se retira (envia a uma atualização com métrica inacessível) a atualização para 10.4.0.0/16 uma vez que observa que o R3 usa o R2 para alcançar 10.4.0.0/16 (após melhor caminho BGP running em todos os caminhos disponíveis):
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 2.2.2.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
65502
192.168.30.4 from 192.168.30.4 (4.4.4.4)
Origin IGP, metric 200, localpref 100, valid, external
Isto permite que o R2 salvar alguma memória desde que não tem que armazenar esta informação inútil. Caso a sessão de BGP entre o R2 e o R4 falhasse, o R2 enviaria uma atualização inacessível ao R3 para 10.4.0.0/16. Esta atualização provocaria o R3 para enviar uma atualização com a rota R3 para 10.4.0.0/16 através do R4 ao R2. O R2 podia começar distribuir através do R3.
O comando bgp deterministic-med
Permitir o comando bgp deterministic-med remove toda a dependência temporal de decisões MED-baseadas do melhor caminho. Assegura-se de que uma comparação precisa de MED esteja feita através de todas as rotas recebidas do mesmo sistema autônomo (COMO).
Se você desabilita o med determinístico BGP, a ordem em que as rotas são recebidas pode impactar decisões MED-baseadas do melhor caminho. Isto pode ocorrer quando a mesma rota é recebida do ASs múltiplo ou da confederação secundário-AS, com exatamente o mesmo comprimento de trajeto, mas os MED diferentes.
Exemplos
Por exemplo, considere as seguintes rotas:
entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10 entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5 entry3: ASPATH 1, MED 200, external
A ordem em que as rotas de BGP foram recebidas é entry3, entry2, e entry1 (o entry3 é a entrada a mais velha na tabela de BGP e o entry1 é o mais novo).
Um BGP Router com med determinístico BGP desabilitado
Um BGP Router com os enfermos do med determinístico BGP escolhe o entry2 sobre o entry1, devido a uma métrica mais baixa IGP alcançar o Próximo salto (o MED não foi usado nesta decisão porque o entry1 e o entry2 são de dois AS diferentes). Prefere então o entry3 sobre o entry2 porque é externo. Contudo, o entry3 tem um MED mais alto do que o entry1. Para obter mais informações sobre do critério de seleção de caminho do BGP, refira o algoritmo de seleção de caminho do melhors BGP.
Um BGP Router com o med determinístico BGP permitido
Neste caso, as rotas do mesmos QUE são agrupados junto, e as melhores entradas de cada grupo são comparadas. No exemplo dado, há dois AS, AS1 e AS2.
Group 1: entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10
entry3: ASPATH 1, MED 200, external
Group 2: entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5
No grupo1, o melhor caminho é entry1 devido ao MED mais baixo (o MED é usado nesta decisão desde que os trajetos são do mesmos QUE). No grupo2, há somente uma entrada (entry2). O melhor caminho é determinado então comparando os vencedores de cada grupo (o MED não é usado nesta comparação à revelia porque os vencedores de cada grupo são dos AS diferentes - permitir o always-compare-med BGP muda este comportamento padrão). Agora, ao comparar o entry1 (vencedor do grupo1) e o entry2 (vencedor do grupo2), o entry2 será o vencedor desde que tem a métrica melhor IGP ao salto seguinte.
Se o always-compare-med BGP foi permitido igualmente que compara então o entry1 (vencedor do grupo1) e o entry2 (vencedor do grupo2), o entry1 será o vencedor devido a um mais baixo MED.
Cisco recomenda permitir o med determinístico BGP em todas as distribuições de rede novas. Além, se o always-compare-med BGP é permitido, as decisões BGP MED são sempre determinísticas.
Para obter mais informações sobre do med determinístico BGP e dos comandos bgp always-compare-med, refira como o comando bgp deterministic-med difere do comando bgp always-compare-med.
Feedback