Para parceiros
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).
Não existem requisitos específicos para este documento.
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. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
MED é um atributo não transitório opcional. O MED é uma dica para vizinhos externos sobre o caminho preferencial em um sistema autônomo (AS) que tem vários pontos de entrada. O MED também é conhecido como a métrica externa de uma rota. Um valor MED mais baixo é preferido a 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 AS vizinho.
Topologia:
Neste cenário, o AS 65502 é um cliente do ISP que tem o AS 65501. 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 |
---|
! 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 de R1 e R3 são semelhantes a R2. R3 tem um eBGP que é correspondente a R4 e um iBGP que é correspondente a R1.
R1 tem um iBGP que é correspondente a R2 e um a R3. Vejamos 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: 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 podemos ver, R2 e R3 escolhem como melhor caminho a rota externa de R4, o que é esperado de acordo com o 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 2 redes, o que está de acordo com a regra do melhor caminho do BGP — selecione o caminho com o menor ID do roteador, tudo o resto sendo igual. Como o ID do roteador R2 é 2.2.2.2 e o ID do roteador R3 é 3.3.3.3, R2 é escolhido. Nesta configuração básica, todo o tráfego para as duas redes no AS 65502 passa de R1 a R2 e, em seguida, para R4 por padrão. Agora suponha que o R4 deseja balancear a carga do tráfego recebido do AS 65501. Para fazer isso sem solicitar que o ISP R4 faça nenhuma modificação, você pode configurar o R4 para utilizar o MED para forçar o tráfego de uma rede em um caminho e o tráfego da outra rede em outro caminho.
Esta é a configuração do R4 depois de aplicarmos 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 |
Observação: você precisa limpar a sessão BGP com o comando clear ip bgp * soft out, por exemplo, para fazer com que essa configuração tome uma ação.
R1 agora vê a rota sobre R2 como o melhor caminho para a rede 10.4.0.0/16 porque a atualização recebida de R2 tem um MED de 100 versus um MED de 200, que é o que R3 anuncia. Da mesma forma, R1 usa R3 e o link R3 - R4 para acessar 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
Vejamos a exibição do 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 R2 mostra apenas um caminho para 10.4.0.0/16 é porque R3 retira (envia uma atualização com métrica inalcançável) a atualização para 10.4.0.0/16 quando percebe que R3 usa R2 para acessar 10.4.0.0/16 (depois de executar o melhor caminho BGP 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
Isso permite que o 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 enviará 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 R3 para 10.4.0.0/16 via R4 para R2. R2 pode começar a rotear através de R3.
Habilitar o comando bgp deterministic-med remove qualquer dependência temporal das decisões de melhor caminho baseadas em MED. 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, a ordem em que as rotas são recebidas pode afetar as decisões de melhor caminho baseadas em 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.
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 BGP foram recebidas é entrada3, entrada2 e entrada1 (entrada3 é a entrada mais antiga na tabela BGP e entrada1 é a mais recente).
Um roteador BGP com bgp deterministic-med desabilitado escolhe entry2 sobre entry1, devido a uma métrica IGP mais baixa para acessar o NEXT_HOP (MED não foi usado nesta decisão porque entry1 e entry2 são de dois ASs diferentes). Em seguida, prefere a entrada3 à entrada2 porque é externa. No entanto, a entrada3 tem um MED superior à entrada1. Para obter mais informações sobre os critérios de seleção de caminho BGP, consulte o algoritmo de seleção de melhor caminho BGP.
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 1 e AS 2.
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 Grupo 1, o melhor caminho é a entrada1 devido ao MED mais baixo (MED é usado nesta decisão porque os caminhos são do mesmo AS). No Grupo 2, há apenas uma entrada (entrada2). O melhor caminho então é determinado comparando os vencedores de cada grupo (MED não é usado nesta comparação por padrão porque os vencedores de cada grupo são de ASs diferentes - habilitando o bgp always-compare-med altera esse comportamento padrão). Agora, ao comparar a entrada1 (o vencedor do Grupo 1) e a entrada2 (o vencedor do Grupo 2), a entrada2 será o vencedor, já que tem a melhor métrica IGP para o próximo salto.
Se o bgp always-compare-med também tiver sido ativado, comparando a entrada1 (o vencedor do Grupo 1) e a entrada 2 (o vencedor do Grupo 2), a entrada 1 será a vencedora devido ao MED mais baixo.
A Cisco recomenda habilitar o bgp deterministic-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 deterministas.
Para obter mais informações sobre os comandos bgp deterministic-med e bgp always-compare-med, consulte Como o Comando bgp deterministic-med se Difere do Comando bgp always-compare-med.