IP : Roteamento IP

Como os Roteadores BGP Usam o Multi-Exit Discriminator para a Seleção do Melhor Caminho

1 Julho 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (23 Março 2012) | Feedback

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Convenções
O Atributo MED
      Exemplo
O Comando bgp deterministic-med
      Exemplos
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Este documento demonstra o uso do comando bgp deterministic-med e explica como ele pode afetar a seleção de caminhos baseada 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 apresentadas 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. Se a sua rede estiver em um ambiente de produção, esteja ciente do impacto potencial de qualquer comando.

Convenções

Para obter mais informações sobre convenções de documentos, consulte as Convenções de Dicas Técnicas da Cisco.

O Atributo MED

O MED é um atributo opcional não transitivo. Ele é uma dica para os vizinhos externos sobre o caminho preferencial para um sistema autônomo que possui vários pontos de entrada. O MED também é conhecido como a métrica externa de uma rota. Um valor de MED baixo é preferido em relação a um valor elevado.

Esta seção descreve um exemplo de como usar o MED para influenciar a decisão de roteamento tomada por um AS vizinho.

Topologia:

37_01.gif

Exemplo

Neste cenário, AS 65502 é um cliente do ISP que possui o AS 65501. R4 está conectado a dois roteadores diferentes no lado do ISP para fins de redundância e anuncia duas redes para o ISP — 10.4.0.0/16 e 10.5.0.0/16. Parte 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 de R1 e R3 são semelhantes às de R2. R3 possui um eBGP peer de R4 e um iBGP peer de R1.

R1 possui um iBGP peer de R2 e outro de 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 observar, tanto R2 quanto R3 escolhem como melhor caminho a rota externa de R4, o que é esperado de acordo com o algoritmo de seleção de melhor caminho do BGP. Consulte Algoritmo de Seleção de Melhor Caminho do BGP para obter mais informações.

Da mesma forma, R1 escolhe R2 para acessar as duas redes, o que está de acordo com a regra de melhor caminho do BGP — selecionar o caminho com a menor ID de roteador, todo o resto é igual. Como a ID do roteador R2 é 2.2.2.2 e a ID do roteador R3 é 3.3.3.3, R2 é escolhido. Nessa configuração básica, todo o tráfego para as duas redes no AS 65502 passa de R1 por R2 e, em seguida, para R4 por padrão. Agora suponha que R4 deseje balancear a carga do tráfego que recebe do AS 65501. Para fazer isso sem pedir que o ISP de R4 faça qualquer modificação, você pode configurar R4 para usar o MED a fim de forçar o tráfego de uma rede por um caminho e o tráfego para a outra rede pelo outro.

Esta é a configuração de R4 após a aplicação da 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

!---  O mapa de rotas MED-R3 aplica um MED 200 à rede 10.4.0.0/16
!--- e um MED 100 à rede 10.5.0.0/16.
!--- O mapa de rotas é aplicado na saída na direção de 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

!---  O mapa de rotas MED-R2 aplica um MED 100 à rede 10.4.0.0/16
!--- e um MED 200 à rede 10.5.0.0/16.
!--- O mapa de rotas é aplicado na saída na direção de R2.

!
!
!
line con 0
 exec-timeout 0 0
line aux 0
line vty 0 4
 exec-timeout 0 0
 login
!
!
end

Nota: Você deve limpar a sessão de BGP com o comando clear ip bgp * soft out, por exemplo, para fazer com que essas configurações entrem em vigor.

R1 agora vê a rota por R2 como o melhor caminho para a rede 10.4.0.0/16 porque a atualização recebida de R2 possui um MED de 100 versus um MED de 200, que é aquele anunciado por R3. 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 de 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 cancela (envia uma atualização com métrica inatingível) a atualização para 10.4.0.0/16 assim que percebe que R3 usa R2 para acessar 10.4.0.0/16 (após executar o melhor caminho de 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 R2 economize alguma memória, já que ele não precisa armazenar essas informações inúteis. Caso a sessão de BGP entre R2 e R4 falhe, R2 enviará uma atualização inatingível para R3 para 10.4.0.0/16. Essa atualização fará com que R3 envie uma atualização com a rota de R3 para 10.4.0.0/16 via R4 ou R2. R2 poderá começar a rotear por R3.

O Comando bgp deterministic-med

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

Se você desabilitar bgp deterministic-med, a ordem nas quais as rotas são recebidas poderá 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 tamanho de caminho, mas com MEDs 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 na qual as entradas de BGP foram recebidas é entry3, entry2 e entry1 (entry3 é a entrada mais antiga na tabela de BGP e entry1 é a mais nova).

Um Roteador BGP com bgp deterministic-med Desabilitado

Um roteador BGP com bgp deterministic-med desabilitado escolhe entry2 em vez de entry1 devido a uma métrica de IGP menor para atingir NEXT_HOP (o MED não foi usado nesta decisão porque entry1 e entry2 pertencem a ASs diferentes). Ele então prefere entry3 em vez de entry2 porque ela é externa. No entanto, entry3 possui um MED maior que entry1. Para obter mais informações sobre os critérios de seleção de caminho do BGP, consulte Algoritmo de Seleção de Melhor Caminho do BGP.

Um Roteador BGP com bgp deterministic-med Habilitado

Nesse caso, as rotas do mesmo AS são agrupadas juntas e as melhores entradas de cada grupo são comparadas. No exemplo fornecido 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

Em Group 1, o melhor caminho é entry1 devido ao MED menor (o MED é usado na decisão porque os caminhos pertencem ao mesmo AS). Em Group 2, há apenas uma entrada (entry2). O melhor caminho é então determinado pela comparação dos vencedores de cada grupo (o MED não é usado nessa comparação por padrão porque os vencedores de cada grupo pertencem a ASs diferentes - a habilitação de bgp always-compare-med altera esse comportamento padrão). Agora, na comparação entre entry1 (a vencedora de Group 1) e entry2 (a vencedora de Group 2), entry2 vencerá porque possui a melhor métrica de IGP para o próximo salto.

Se bgp always-compare-med também estava habilitado durante a comparação de entry1 (vencedora de Group 1) com entry2 (vencedora de Group 2), entry1 vencerá devido ao MED menor.

A Cisco recomenda habilitar bgp deterministic-med em todas as novas implementações de rede novas. Além disso, se bgp always-compare-med estiver habilitado, as decisões de MED do NGP serão sempre determinísticas.

Para obter mais informações sobre os comandos bgp deterministic-med e bgp always-compare-med, consulte Como o Comando bgp deterministic-med Difere do Comando bgp always-compare-med.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 13759