Use o Multi-Exit Discriminator para selecionar o melhor caminho para o roteador BGP

Introdução

Este documento descreve o bgp deterministic-med e explica como ele afeta a seleção de caminho com base no discriminador de várias saídas (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 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 documento, consulte as Convenções de dicas técnicas Cisco.

O Atributo MED

MED é um atributo não transitivo opcional. MED é uma dica para vizinhos externos sobre o caminho preferido 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 tem preferência 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 AS vizinho.

Topologia de rede 

Topologia de rede

Exemplo

Neste cenário, AS 65502 é um usuário do ISP que tem 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.

!
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

!
version 12.3
!
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 de R1 e R3 são semelhantes a R2. R3 tem um eBGP que corresponde a R4 e um iBGP que corresponde a R1.

R1 tem um iBGP que corresponde a R2 e 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 como melhor caminho 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 2 redes, o que está de acordo com a regra do melhor caminho BGP—selecione o caminho com o menor ID de roteador. Como o ID do roteador R2 é 10.2.2.2 e o ID do roteador R3 é 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 queira balancear a carga do tráfego que recebe do AS 65501. Para fazer isso sem nenhuma modificação do ISP R4, você configura o 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.

Esta é a configuração de R4 depois que você aplica a configuração necessária:

!
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 essas configurações executem uma ação.

R1 agora vê a rota em 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 10.2.2.2 (10.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 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 100, localpref 100, valid, internal, best

Examine a tela 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:
  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

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 uma vez que percebe que R3 usa R2 para acessar 10.4.0.0/16 (depois que você executa 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 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 via R3.

O comando bgp deterministic-med

Se você habilitar o comando  bgp deterministic-med    remove qualquer dependência temporal de decisões de melhor caminho baseadas em MED. Ele garante que uma comparação MED precisa seja feita em todas as rotas recebidas do mesmo sistema autônomo (AS).

Se você desativar o bgp deterministic-med , a ordem na qual 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.

Examples

Por exemplo, considere as próximas 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 na qual as rotas BGP foram recebidas é entrada3, entrada2 e entrada1 (entrada3 é a entrada mais antiga na tabela BGP e entrada1 é a mais nova).

Um roteador BGP com bgp deterministic-med desativado

Um roteador BGP com bgp deterministic-med desativado escolhe a entrada2 em vez da entrada1, devido a uma métrica IGP mais baixa para acessar o NEXT_HOP (MED não foi usado nesta decisão porque a entrada1 e a entrada2 são de dois ASs diferentes). Em seguida, ele prefere a entrada3 em vez da entrada2, pois ela é externa. No entanto, a entrada3 tem um MED maior que a entrada1. 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 bgp deterministic-med habilitado

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 entrada 1 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. Quando você habilita bgp always-compare-med   ele altera esse comportamento padrão). Agora, quando você compara o entry1 (o vencedor do Grupo 1) e o entry2 (o vencedor do Grupo 2), o entry2 pode ser o vencedor, já que tem a melhor métrica IGP para o próximo salto.

Se bgp always-compare-med   O também foi habilitado quando você compara o item 1 (o vencedor do Grupo 1) e o item 2 (o vencedor do Grupo 2), o item 1 pode ser o vencedor devido ao MED inferior.

A Cisco recomenda que você habilite bgp always-compare-med em todas as novas implantações de rede. Além disso, se bgp always-compare-med estiver ativado, as decisões MED do BGP são sempre determinísticas.

Para obter mais informações sobre o bgp deterministic-med e o 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