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

Opções de download

PDF (192.6 KB)
Ver no Adobe Reader em vários dispositivos
ePub (106.6 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

Linguagem livre de preconceitos

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

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.

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

O atributo MED

Exemplo

O comando bgp deterministic-med

Examples

Informações Relacionadas

Introduction

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).

Prerequisites

Requirements

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. 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.

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 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:

Exemplo

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

!
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

!
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

!
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.

O comando bgp deterministic-med

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.

Examples

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 desativado

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.

Um roteador BGP com bgp deterministic-med ativado

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.