Guest

Como os roteadores BGP usam o Multi-Exit Discriminator para a seleção do melhor caminho

Opções de download

  • PDF     (112.5 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (98.0 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (130.1 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:23 de Março de 2012
ID do documento:13759
Sobre a tradução

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

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:

37_02.gif

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.

Informações Relacionadas

Colaborado por engenheiros da Cisco

Este documento lhe foi útil?

FeedbackFeedback

Deixe-nos ajudar

Discussões relacionadas ao produto na comunidade de suporte