Vous êtes sur la page 1sur 84

c   


3 Abril 2008YY
Y 
Y

 Y

 Y
  Y
Requisitos
Componentes Usados
Convenções
YY YYYY
Como funciona o BGP?
eBGP e iBGP
Ativar roteamento de BGP
Forme vizinhos de BGP
Interface de loopback e de BGP
eBGP multihop
eBGP Multihop (Balanceamento de carga)
Mapas de rotas
Comandos de configuração corresponder e definir
Comando de rede
Redistribuição
Redistribuição e rotas estáticas
iBGP
O algoritmo de decisão do BGP
YY YYYY
Atributo AS_PATH
Atributo de origem
Próximo atributo de nó do BGP
Backdoor de BGP
Sincronização
Atributo de ponderação
Atributo de preferência local
Atributo de métrica
Atributo de comunidade
YY YYYY
Filtragem de BGP
Expressão regular do AS
Vizinhos de BGP e mapas de rotas
YY YYYY
Endereços agregados e de CIDR
Confederação de BGP
Refletores de rota
Retarndamento de sincronismo de rota
Com o BGP seleciona um caminho
YY YYYY
Exemplo de projeto prático
 YY !Y  YY "YY#
 $%Y&
  Y

 YY

Este documento contém cinco estudos de caso do Protocolo de gateway limite (BGP).

  YY

&  YY

Não existem requisitos específicos para este documento.

!  Y'YY

Este documento não está restrito a versões específicas de software e de hardware.

 " %YY

Consulte Convenções de Dicas Técnicas da Cisco para obter mais informações sobre as convenções de
documentos.

YY YYYYY

O BGP, que o RFC 1771 define, permite que você crie roteamentos de interdomínio sem loop entre
sistemas autônomos (ASs). Um AS é um conjunto de roteadores em uma única administração técnica.
Roteadores em um AS podem usar vários Gateway Protocols interiores (IGPs) para trocar informações de
roteamento dentro do AS. Os roteadores podem usar um protocolo de gateway exterior para rotear pacotes
fora do AS.

Y$  YY(YY

O BGP usa TCP como o protocolo de transporte na porta 179. Dois roteadores BGP formam uma conexão
TCP entre um e outro. Esses roteadores são de peer. Os roteadores de peer trocam mensagens para abrir e
confirmar os parâmetros de conexão.

Roteadores BGP trocam informações de alcançabilidade de rede. Esta informação é principalmente um


indício dos caminhos completos que uma rota deve tomar para alcançar a rede de destino. Os camihos são
números de AS de BGP. Esta informação ajuda na construção de um gráfico de ASs sem loop. O gráfico
também mostra onde aplicar políticas de rota para reforçar algumas restrições ao comportamento de
roteamento.

Quaisquer dois roteadores que formem uma conexão TCP para trocar informaç~es de roteamento BGP são
"peers" ou "vizinhos". Peers BGP inicialmente trocam todas as tabelas de roteamento BGP. Após esta troca,
os peers enviam atualizações incrementais conforme as tabelas de roteamento mudam. BGP mantém um
número de versão da tabela BGP. O número de versão é o mesmo para todos os peers BGP. O número de
versão muda quando o BGP atualiza a tabela com mudanças de informação de roteamento. O envio de
pacotes de manutenção de atividade garante que a conexão entre os peers BGP está ativa. Pacotes de
notificação são enviados em resposta a erros ou condições especiais.

YY YY

If an AS has multiple BGP speakers, the AS can serve as a transit service for other ASs. Conforme o
diagrama nesta seção mostra, AS200 é um AS de trânsito para o AS100 e o AS300.

Para enviar as informações a Ass excternos, é preciso ter uma garantia de alcançabilidade para redes. Para
garantir a alcançabilidade de redes, ocorrem os seguintes processos:

AY Correspondência de BGP interno (iBGP) entre roteadores dentro de um AS


AY Redistribuição de informações de BGP para IGPs que executam no AS

Quando o BGP é executado entre roteadores que pertencem a dois ASs diferentes, é chamado BGP exterior
(eBGP). Quando o BGP é executado entre roteadores que no mesmo AS, é chamado iBGP.

a "Y YYYY

Conclua essas etapas para ativar e configurar o BGP.

Suponha que você deseja que dois roteadores, RTA e RTB, comuniquem-se por BGP. No primeiro exemplo,
RTA e RTB estão em ASs diferentes. No segundo exemplo, ambos os roteadores pertencem ao mesmo AS.

1.YDefina o processo de roteador e o número de AS para o qual os roteadores pertencem.

Emita este comando para habilitar O BGP em um roteador:

YYYYYYYYYYYYYYYYYYÔ ÔV  


Y
Y
Y
Y Y
Y
Y
Y
Y Y
Estas instruções indicam que o RTA executa o BGP e pertence ao AS100. O RTB executa BGP e
pertence a AS200.

2.YDefina vizinhos de BGP.

A formação de vizinhos de BGP indica os roteadores que tentam comunicar-se através de BGP. A
seção Forme vizinhos de BGP explica este processo.

^Y" ) *YYYY

Dois roteadores BGP tornam-se vizinhos após estabelecerem uma conexão TCP um com o outro. A conexão
TCP é essencial para que os dois roteadores peer iniciem a troca de atualizações de roteamento.

Após estabelecerem a conexão TCP, os roteadores envuam mensagens abertas para trocar valores. Os
valores trocados pelos roteadores incluem o número de AS, a versão de BGP executada pelos roteadores, a
ID dos roteadores BGP e o tempo de espera da manutenção de atividade. Após a confirmação e aceitação
destes valores, é estabelecida a conexão vizinha. Qualquer status diferente de c   é uma
indicação de que os dois roteadores não tornaram-se vizinhos e que não podem trocar atualizações de BGP.

Emita este comando  +*, para estabelecer uma conexão TCP:

YYYYYYYYYYYY{  ÔipV
Ô
   

Y
YYYYYYYYYY
O { Yno comando é o número de AS de um dos roteadores aos quais você deseja conectar-se com
BGP. O { Yé o próximo endereço de nó com conexão direta para eBGP. Para iBGP, o {
 Yé qualquer endereço de IP no outro roteador.

Os dois endereços de IP que você usa no comando  +*, dos roteadores peer ½  ser capazes de
alcançar um ao outro. Um jeito de verificar a alcançabilidade é um ping extendido entre os dois endereços
de IP. O ping extendido força o roteador excutando o comando ping a usar como fonte o endereço de IP que
o comando  +*, especifica. O roteador precisa usar este endereço em vez do endereço de IP da
interface de onde vem o pacote.

Se houver qualquer alteração na configuração do BGP, você ½   reiniciar a conexão vizinha para
permitir que os novos parâmetros entrem em vigor.

AY
Y !Y,+!YV

,"-YO {Yé o do vizinho.

AY
Y !Y,+!Y.

Este comando limpa todas as conexões vizinhas.

Por padrão, sessões de BGP iniciam-se com o uso da versão 4 do BGP e negociam para versões anteriores,
se necessário. Você pode impedir negociações e forçar a versão de BGP utilizada pelos roteadores a
comunicar-se com um vizinho. Emita este comando no modo de configuração de roteador:

YYYYYYYYYYYY{  Ôip V
p

 pV
Ô  { V 
Y
YYYYYYYYYY
Segue um exemplo de configuração do comando  +*,:
Y
Y
Y Y

 Y    Y Y Y
Y
Y
Y
Y Y

 Y   Y Y Y

 Y   Y Y Y
Y
Y
Y
Y Y

 Y    Y Y Y
Neste exemplo, RTA e RTB executam eBGP. RTB e RTC executam iBGP. O número de AS aponta para
um AS interno ou externo, o que indica se eBGP ou iBGP. Além disso, os peers de eBGP têm conexão
direta, mas os peers de iBGP não têm conexão direta. Roteadores iBGP não precisam de conexão direta.
Mas é necessário haver algum IGP que executa e permite que os dois vizinhos alcancem um ao outro.

Esta seção fornece um exemplo das informações que o comando */Y !Y,+!Y  +*, exibe.

,"-YPreste muita atenção ao estado do BGP. Qualquer status diferente de c   Isso
indica que os peer não estão ativados.

,"-YAlém disso, observe estes itens:

AY A ë Y , que é 4


AY A  YYY

Este número é o endereço IP mais alto do roteador ou a interface de loopback mais alta, se
existente.

AY A ë YY 

A ë YY  fornece o estado da tabela. Sempre que chegar novas informações, a tabela
aumenta a versão. Uma versão que continua a incrementar indica que há algum sincronismo de rota
que causa a atualização contínua dos roteadores.

Y {  Ô Y
YYYYY Y
 Y Y    !YY"Y !Y#Y
$Y
YYYYY Yë Y%!YYY Y    Y
YYYYY       !Y Yë Y&Y!Y Y
'Y ( (Y
YYYYY) YY ( (!YYY Y * !Y$ ëY
ëY Y+ Y  Y
YYYYY,YY -Yë Y Y Y Y  Y
YYYYY ëY**Y 
 !Y Y' !Y YY.Y
YYYYY"Y*+Y 
 !Y Y' !Y YY.Y
YYYYY Y   Y /Y Y YY
 $ YY
!, 0YYYYY

O uso de uma interface de loopback para definir vizinhos é comum com o iBGP, mas não com o eBGP.
Normalmente, utiliza-se a interface de loopback para garantir que o endereço de IP do vizinho permanece
ativo e é independente de hardware que funciona apropriadamente. No caso do eBGP, roteadores de peer
freqüentemente possuem conexão direta e loopback não se aplica.

Se você usar o endereço de IP de uma interface de loopback no comandoY  +*,Y, precisará de


configurações extras no roteador vizinho. O roteador vizinho precisa informar o BGP da utilização de uma
interface de loopback em vez de uma interface física para iniciar a conexão de TCP do vizinho de BGP. Para
indicar uma interface de loopback, emita este comando:

YYYYYYYYYYYY{  ÔipV
  Ôi
V
Y
YYYYYYYYYY
Este exemplo ilustra a utilidade deste comando :

Y
YYYYYY
Y Y
YYYYY
 Y    Y Y Y
YYYYY
 Y    Y  Y $Y Y
Y
YYYYYY
Y Y
YYYYY
 Y     Y Y YY
Neste exemplo, RTA e RTB executam iBGP dentro do AS100. No comando  +*,, o RTB utiliza a
interface de loopback do RTA, 150.212.1.1. Neste caso, o RTA deve forçar o BGP a utilizar o endereço de
IP do loopback como fonte na conexão vizinha de TCP. Para forçar esta ação, o RTA adiciona !
 Y{  V   Y{  V  {Ypara que o comando seja  +*,Y12333Y! Y

!, 0Y. Estas instruções forçam o BGP a usar o endereço de IP da interface de loopback quando o BGP
comunica-se com o vizinho 190.225.11.1.

,"-YO RTA utilizou o endereço de IP da interface física do RTB, 190.225.11.1, como um vizinho.
O uso deste endereço de IP é a razão porque o RTB não precisa de configurações especiais. Consulte
Configuração de exemplo para iBGP e eBGP com ou sem um endereço de loopback para a configuração de
exemplo de um cenário de rede completo.

Y
 *!YY

Em alguns casos, um roteador Cisco pode executar eBGP com um roteador de terceiros que não permite
conexão direta dos dois peers externos. Para alcançar a conexão, você pode usar o eBGP multihop. O eBGP
multihop permite uma conexão vizinha entre dois peers externos que não possuem conexão direta. O
multihop serve apenas para o eBGP e não para o iBGP. Este exemplo ilustra o eBGP multihop:

Y
Y
Y Y

 Y *   Y Y Y

 Y *   Y
 Y
Y
Y
Y Y

 Y   Y Y Y
O RTA indica um vizinho externo que não possuem conexão direta. O RTA precisa indicar sua utilização do
comando ,+!
 *!. Por outro lado, o RTB indica um vizinho que tenha conexão direta, que é
129.213.1.2. Por causa desta conexão direta, o RTB não precisa do comando ,+!
 *!. Você também
deve configurar um roteamento de IGP ou estático para permitir que vizinhos sem conexão alcancem um ao
outro.

O exemplo na seção eBGP multihop (Balanceamento de carga) mostra como alcançar o balanceamento de
carga sem BGP em um caso em que você tenha um eBGP sobre linhas paralelas.

Y
 *!Y4
  YY +5YY

Y
Y $Y Y
 Y Y     Y Y
Y
Y Y

 Y +    Y Y Y

 Y +    Y
 Y

 Y +    Y  Y $Y Y
-$Y     Y
Y
 YY +    Y  Y   Y
 YY +    Y  YY
Y
Y $Y Y
 Y Y +    Y Y
Y
Y Y

 Y     Y Y Y

 Y     Y  Y $Y Y

 Y     Y
 Y
-$Y +    Y
Y
 YY     Y  Y    Y
 YY     Y  Y Y
Este exemplo ilustra a utilização de interfaces de loopback, 
)$  e ,+!
 *!. O exemplo é
uma solução para alcançar o balanceamento de carga entre dois interlocutores eBGP sobre linhas seriais
paralelas. Em situações normais, o BGP escolhe uma das linhas para enviar pacotes e o balanceamento de
carga não ocorre. Com a introdução de interfaces de loopback, o próximo nó para o eBGP é a interface de
loopback. È possível utilizar rotas estáticas ou um IGP para apresentar dois caminhos de custo igual para
atingir o destino. O RTA possui duas opções para alcançar o próximo nó 160.10.1.1: um caminho através do
1.1.1.2 e o outro através do 2.2.2.2. O RTB possui as mesmas opções.

!YYYY

Há utilização extensa de mapas de rotas com o BGP. No contexto do BGP, o mapa de rotas é um método
usado para controlar e modificar informações de roteamento. O controle e a modificação de informações de
roteamento ocorrem pela da definição de condições para redistribuição de rotas de um protocolo de
roteamento para o outro. Ou o controle das informações de roteamento pode ocorrer em uma injeção dentro
e fora do BGP. Segue o formato do mapa de rotas:

YYYYYYYYYYYYÔ 
VpV Ô
{ 
   
Y
YYYYYYYYYY
O caractere de mapa é somente um nome que você dá ao mapa de rotas. Você pode definir diversas
instâncias do mesmo mapa de rotas, ou do mesmo caractere de nome. O número de seqüência é
simplesmente uma indicação da posição que um novo mapa de rotas terá na lista de mapas de rotas que já
está configurada com o mesmo nome.

Neste exemplo, duas instâncias do mapa de rotas estão definidas com o nome MEUMAPA. A primeira
instância possui um número de seqüência de 10 e a segunda tem um número de seqüência de 20.

AY !Y6aY! Y2 (O primeiro conjunto de condições vai aqui.)


AY !Y6aY! Y2 (O segundo conjunto de condições vai aqui.)
Ao aplicar o mapa de rotas MEUMAPA A rotas de entrada ou de saída, o primeiro conjunto de condições é
aplicado pela instância 10. Se o primeiro conjunto de condições não for atingido, siga até uma instância
maior do mapa e rotas.

 YY  $ +Y ! YY$ YY

Cada mapa de rotas consiste de uma lista de comandos de configuração  * e . Corresponder
especifica um critério  *, e definir especifica uma ação  se o critério que o comando  * aplica
não for atingido.

Por exemplo, é possível dfinir um mapa de rotas que verifica atualizações de saída. Se houver uma
correspondência para o endereço de IP 1.1.1.1, a métrica para esta atualização está configurada para 5. Estes
comandos ilustram o exemplo:

YYYYYYYYYYYY
  Ô    
Y
YYYYYYYYYYYY 
Ôü
Y
YYYYYYYYYY
Agora, se os critérios de correspondência forem atingidos e você possuir uma ! , haverá
redistribuição ou controle das rotas, conforme especificado pela ação configurada. Você sairá da lista.

Se os critérios de correspondência forem atingidos e você possuir uma +, não haverá redistribuição
ou controle das rotas. Você sairá da lista.

Se os critérios de correspondência não forem atingidos e você possuir uma ! YY +, a
próxima instância do mapa de rotas será verificada. Por exemplo, a instância 20 é verificada. Esta
verificação de próxima instância continuará até que você saia ou termine todas as instâncias do mapa de
rotas. Se a lista terminar e não houver correspondência, a rota Y7Y  YY  *.

Em versões do Cisco IOS® Software anteriores à versão 11.2 do Cisco IOS Software, ao utilizar os mapas
de rota para filtrar atualizações de BGP em vez de redistribuir entre protocolos, você { ½ filtrar na
entrada quando utilizar um comando  * no endereço de IP. Um filtro na saída é aceitável. Versões 11.2
e posteriores do Cisco IOS Software não possuem essa restrição.

Os comandos relacionados para  * são:

AY  *Y!*Y
AY  *Y  8
AY  *Y

AY  *Y $ 
AY  *Y !Y
AY  *Y !Y 9*!
AY  *Y !Y 
AY  *Y
AY  *Y8!
AY  *Y+

Os comandos relacionados para  são:

AY Y!*
AY Y

AY Y +
AY Y  8
AY Y $ 
AY Y$
Y $ 
AY Y !Y$
Y 9*!
AY Y
"

AY Y
 
!$ 
AY Y
AY Y 8!
AY Y 9*!
AY Y +
AY Y+
AY Y/ +*

Veja alguns exemplos de mapas de rota:

9!
YYY

Suponhamos que RTA e RTB executam RIP (Protocolo de informações de roteamento), e que RTA e RTC
executam BGP. O RTA é atualizado pelo BGP e redistribui aa atualizações para o RIP. Suponhamos que o
RTA deseje redistribuir para o RTB sobre 170.10.0.0 com uma métrica 2 e todas as outras rotas com uma
métrica 5. Neste caso, é possível utilizar esta configuração:

Y
Y Y
-$Y   Y
-$Y   Y
-$Y     Y
 ë'Y" Y
  Y
Y Y Y"c,c Y
Y
Y
Y Y

 YY Y Y
-$Y     Y
Y
 Y"c,c Y Y Y
Y  Y Y
YYY
Y
 Y"c,c Y Y Y
YYY
Y
  Y Y Y     Y  Y
Neste exemplo, se uma rota corresponde ao endereço de IP 170.10.0.0, ela possui métrica 2. Assim, você sai
da lista de mapas de rotas. Se não há correspondência, você continua a descer a lista de mapas de rotas, o
que indica configurar tudo mais para a métrica 5.

,"-YSempre faça a pergunta "O que acontece a roteadores que não correspondem a nenhuma das
instruções de correspondência?" Estas rotas são descartadas, por padrão.

9!
YYY

Suponhamos que, no Exemplo 1, você não queira que o AS100 aceite atualizações sobre 170.10.0.0. Não é
possível aplicar mapas de rotas na entrada quando você corresponde a um endereço de IP como base. Então,
você deve utilizar um mapa de rota de saída no RTC:

Y
Y
Y
Y Y
-$Y     Y

 YY Y Y

 YY Y"0 1 c"YY
Y
 Y"0 1 c"Y Y Y
Y Y Y Y
Y
  Y Y2Y     Y  Y
  Y Y Y    YY
Agora que você está mais familiarizado com o processo de como iniciar o BGP e como definir um vizinho,
veja como iniciar a troca de informações de rede.

Há diversas maneiras de enviar informações de rede com a utilização do BGP. Estas seções percorrem os
métodos um por um:

AY Comando de rede
AY Redistribuição
AY Redistribuição e rotas estáticas

 YYYY

O formato do comando /0 é.

YYYYYYYYYYYY{ Ô
  


VY
YYYYYYYYYY
O comando /0 controla as redes que originam desta caixa. Este conceito é diferente da configuração
familiar com IGRP(Protocolo de roteamento de gateway interior) e RIP. Com este comando, não tente
executar o BGP em certa interface. Em vez disso, tente indicar ao BGP que redes ele deveria originar desta
caixa. O comando utiliza uma porção de máscara pois a versão 4 do BGP (BGP4) suporta sub-rede e super-
rede. Um máximo de 200 entradas do comando /0 é aceitável.

O comando /0 funciona se o roteador conhece a rede que você está tentando anunciar, quer esteja
conectada, seja estática, ou obtida dinamicamente.

Um exemplo do comando /0 é:

Y
Y
Y Y
-$Y    Y $Y  Y
 YY    Y  YY Y
Este exemplo indica que o roteador A gera uma entrada de rede para 192.213.0.0/16. O /16 indica que você
utiliza uma super-rede do endereço de classe C e você anuncia os dois primeiros octetos, ou os primeiros 16
bits.

,"-YVocê precisa de uma rota estática para fazer o roteador gerar 192.213.0.0 pois a rota estática
coloca uma entrada correspondente na tabela de roteamento.

&  , YY

O comando /0 é um modo de anunciar suas redes pelo BGP. Outro modo é redistribuir seu IGP no
BGP. Seu IGP pode ser IGRP, protocolo Open Shortest Path First (OSPF), RIP, Protocolo de roteamento de
gateway interior melhorado (EIGRP) ou outro protocolo. Esta redistribuição pode parecer assustadora, pois
você descarrega todas as suas rotas internas no BGP; algumas dessas rotas foram obtidas por BGP e você
não precisa enviá-las de novo. Aplique um filtro cuidadoso para garantir o envio para rotas somente internet
que você queira anunciar e não para todas as rotas que você possui. Segue um exemplo:

O RTA anuncia 129.213.1.0 e o RTC anuncia 175.220.0.0. Observe a configuração do RTC:

Se emitir o comando /0 você possui:

Y
Y
 Y Y
-$Y    Y
  Y
Y Y
'Y Y Y Y Y  Y
Y
Y
Y Y

 Y    Y Y Y
-$Y    Y $Y  Y
Y
YYYYYYYYYYYYYYY YY Y Y
Y  YY YY

 Y
YY
YYYYYYYYYYYYY
YYYYYYYYYY
Se, em vez disso, utilizar a redistribuição, você possui:

Y
Y
 Y Y
-$Y    Y
  Y
Y Y
'Y Y Y Y Y  Y
Y
Y
Y Y

 Y    Y Y Y
  Y
 Y Y
Y
YYYYYYYYYYYYYYY YYY  Y !Y"   Y
Y#Y
YYYYYYYYYYYYY
YYYYYYYYYY
Essa redistribuição provoca a origem de 129.213.1.0 pelo seu AS. Você não é a origem de 129.213.1.0;
AS100 é a origem. Portanto você deve utilizar filtros para impedir a origem de sair daquela rede pelo seu
AS. A configuração correta é:

Y
Y
 Y Y
-$Y    Y
  Y
Y Y
'Y Y Y Y Y  Y
Y
Y
Y Y

 Y    Y Y Y

 Y    Y   Y YY
  Y
 Y Y
Y
  Y Y Y    Y  Y
Você utiliza o comando  
 para controlar as redes que originam do AS200.

Redistribuição de OSPF no BGP é ligeiramente diferente de distribuição para outros IGPs. Simplesmente
executar   ,Y!$Y sob Y,+! não funciona. Palavras-chave específicas, como  
,
9 
, e 9 
são necessárias para redistribuir as respectivas rotas. Consulte Compreensão de
redistribuição de rotas do OSPF no BGP para obter mais detalhes.

&  , YYY7 YY

É sempre possível utilizar rotas estáticas para originar uma rede ou sub-rede. A única diferença é que o BGP
considera que essas rotas possuem uma origem incompleta ou desconhecida. É possível chegar ao mesmo
resultado a que o exemplo na seção chegou Redistribuição com isto:

Y
Y
 Y Y
-$Y    Y
  Y
Y Y
'Y Y Y Y Y  Y
Y
Y
Y Y

 Y    Y Y Y
  Y Y
Y
 YY    Y Y Y
Y
A interface 

2 significa ignorar o pacote. Portanto, se você receber o pacote e houver uma


correspondência mais específica do que 175.220.0.0, que existe, o roteador envia o pacote para a
correspondência específica. Caso contrário, o roteador ignora o pacote. Este método é um bom modo de
anunciar uma super-rede.

Este documento discutiu como utilizar diferentes métodos para originar rotas do seu AS. Lembre-se que
essas rotas são geradas além de outras rotas de BGP que o BGP aprendeu através de vizinhos, internos ou
externos. O BGP passa informações que aprende de um peer para outros peers. A diferença é que rotas que
geram do comando /0, redistribuição, ou estática indicam seu AS como a origem destas redes.

Redistribuição é sempre o método de injeção de BGP no IGP.

Segue um exemplo:

Y
Y
Y Y

 Y    Y Y Y
-$Y     Y
Y
Y
Y
Y Y

 Y +   Y Y Y
-$Y +    Y
Y
Y
Y
Y Y

 Y     Y Y Y

 Y +    Y Y Y
-$Y    Y
,"-YVocê não precisa da rede 150.10.0.0 ou 160.10.0.0 no RTC a não ser que deseje que o RTC
gere essas redes quando passá-las adiante conforme elas vêm de AS100 e AS200. Novamente, a diferença é
que o comando /0 adiciona um anúncio extra para essas mesmas reds, o que indica que AS300
também é uma origem para essas rotas.

,"-YLembre-se que BGP não aceita atualizações originadas de seu próprio AS. Esta recussa
garante uma topologia de interdomínio sem loop.

Por exemplo, suponhamos que o AS200, do exemplo nesta seção, tenha uma conexão de BGP no AS100. O
RTA gera uma rota 150.10.0.0 e envia a rota para AS300. Depois, o RTC passa essa rota para o AS200 e
mantém a origem como AS100. O RTB passa 150.10.0.0 para AS100 com a origem ainda AS100. O RTA
percebe que a atualização originou de seu próprio AS e ignora sua própria atualização.

YY

Utilize o iBGP se um AS desejar agir como sistema de trânsito para outro ASs. É verdade que você pode
fazer o mesmo ao aprender por eBGP, redistribuir no IGP e então redistribuir novamente em outro AS? Sim,
mas o iBGP oferece mais flexibilidade e mais modos eficientes de trocar informações em um AS. Por
exemplo, o iBGP fornece modos de controlar o melhor ponto de saída do AS utilizando a preferência local.
A seção Atributo de preferência local fornece mais informações sobre preferência local.
Y
Y
Y Y

 Y     Y Y Y

 Y    Y Y Y
-$Y     Y
Y
Y
Y
Y Y

 Y     Y Y Y

 Y  %  Y Y% Y
-$Y     Y
Y
Y
Y
Y% Y

 Y  % Y Y Y
-$Y    Y
,"-YLembre-se que quando um interlocutor de BGP recebe uma atualização de outros
interlocutores de BGP em seu próprio AS (iBGP), o locutor de BGP que recebeu a atualização não
redistribui essas informações para outros interlocutores de BGP em seu próprio AS. O interlocutor de BGP
que recebe a atualização redistribui as informações para outros interlocutores de BGP fora de seu AS.
Portanto, sustenta uma malha cheia enre os locutores de iBGP dentro de um AS.

No diagrama nesta seção, RTA e RTB executam iBGP. RTA e RTD também executam iBGP. As
atualizações do BGP que vêm do RTB para o RTA transmitem para o RTE, que fica fora do AS. As
atualizações não transmitem para o RTD, que fica dentro do AS. Portanto, faça uma correspondência de
iBGP entre RTB e RTD para não quebrar o fluxo das atualizações.

Y
+ YY YYYY

Após o BGP receber atualizações sobre diferentes destinos de diferentes sistemas autônomos, o protocolo
deve escolher caminhos para alcançar um destino específico. O BGP escolhe apenas um único caminho para
alcançar um destino específico.
O BGP baseia a decisão em diferentes  ,, como próximo nó, influências administrativas, preferência
local, origem de rota, comprimento de caminho, código de origem, métrica e outros atributos.

O BGP sempre propaga o melhor caminho para os vizinhos. Para obter mais informações, consulte
Algoritmo de Seleção de Melhor Caminho BGP .

A seção Estudos de caso do BGP 2 explica estes atributos e seus usos.

YY YYYYY

a ,Ya :a ;YY

Quando uma atualização de rota passa por um AS, o número de AS é anexado à atualização. O atributo
AS_PATH é, na verdade, a lista de números de AS que uma rota percorreu para alcançar um destino. Um
AS_SET é um conjunto matemático ordenado {} de todos os ASs que foram percorridos. A seção Exemplo
de CIDR 2 (as-set) deste documento fornece um exemplo de AS_SET.

No exemplo nesta seção, o RTB anuncia a rede 190.10.0.0 no AS200. Quando a rota percorre o AS300, o
RTC anexa seu prórprio número de AS à rede. Portanto, quando 190.10.0.0 alcança o RTA, a rede possui
dois números de AS anexados: primeiro 200, depois 300. Para o RTA, o caminho para alcançar 190.10.0.0 é
(300, 200).

O mesmo processo aplica-se a 170.10.0.0 e 180.10.0.0. O RTB precisa pegar o caminho (300, 100); o RTB
percorre o AS300 e depois o AS100 para alcançar 170.10.0.0. O RTC precisa percorrer (200) para alcançar
190.10.0.0 e o caminho (100) para alcançar 170.10.0.0.

a ,YY +YY

A origem é um atributo imperativo que define a origem das informações do caminho. O atributo de origem
pode assumir três valores:

AY IGP ² Informação de alcançabilidade de camada de rede (NLRI) é interior ao AS de origem. Isso


normalmente acontece ao emitir o comando ,+!Y /0. Um  na tabela BGP indica IGP.
AY EGP ² NLRI foi aprendida pelo EGP (protocolo de gateway exterior). Um  na tabela BGP indica
EGP.
AY INCOMPLETO ² NLRI é desconhecida ou foi aprendida por outros meios. INCOMPLETO
normalmente ocorre ao redistribuir rotas de outros protocolos de roteamento no BGP e a origem da
rota está incompleta. Um G na tabela BGP indica INCOMPLETO.

Y
Y
Y Y

 Y     Y Y Y

 Y    Y Y Y
-$Y     Y
  Y Y
Y
 YY     Y  Y Y
Y
Y
Y
Y Y

 Y     Y Y Y
-$Y     Y
cY
Y
Y Y

 Y     Y Y Y
-$Y     Y
O RTA alcança 170.10.0.0 por 300 i. O "300 i" significa que o próximo caminho de AS é 300 e a origem da
rota é IGP. O RTA também alcança 190.10.50.0 por i. Este "i" significa que a entrada é no mesmo AS e a
origem é IGP. O RTE alcança 150.10.0.0 por 100 i. O "100 i" significa que o próximo de AS é 100 e a
origem é IGP. O RTE também alcança 190.10.0.0 por 100 ?. O "100 ?" significa que o próximo AS é 100 e
que a origem está incompleta e vem de uma da rota estática.

<9 Y ,YY <YYY Y


O próximo atributo de nó do BGP é o próximo endereço de IP de nó a ser usado para alcançar certo destino.

Para eBGP, o próximo nó é sempre o endereço de IP do vizinho especificado pelo comando  +*,. No
exemplo nesta seção, o RTC anuncia 170.10.0.0 para o RTA com um próximo nó de 170.10.20.2. O RTA
anuncia 150.10.0.0 para o RTC com um próximo nó de 170.10.20.1. Para iBGP, o protocolo determina que
o próximo nó anunciado pelo eBGP deve ser carregado para o iBGP. Por causa dessa regra, o RTA anuncia
170.10.0.0 para seu peer do iBGP, RTB, com um próximo nó de 170.10.20.2. Portanto, de acordo com o
RTB, o próximo nó a alcançar 170.10.0.0 é 170.10.20.2 e {  150.10.30.1.

Certifique-se de que o RTB pode alcançar 170.10.20.2 pelo IGP. Caso contrário, o RTB descarta pacotes
com o destino de 170.10.0.0, pois o endereço do próximo nó é inacessível. Por exemplo, se o RTB executar
o iGRP, também é possível executar o iGRP na rede 170.10.0.0 do RTA. Você deve tornar o iGRP passivo
no link ao RTC para que o BGP seja apenas trocado.

Y
Y
Y Y

 Y    Y Y Y

 Y     Y Y Y
-$Y     Y
Y
Y
Y Y

 Y     Y Y Y
Y
Y
Y Y

 Y     Y Y Y
-$Y     YY
,"-YO RTC anuncia 170.10.0.0 para o RTA com um próximo nó equivalente a 170.10.20.2.

,"-YO RTA anuncia 170.10.0.0 para o RTB com um próximo nó equivalente a 170.10.20.2. O
próximo nó do eBGP é carregado no iBGP.

Tome cuidade especial ao lidar com redes de multiacesso e de multiacesso sem broadcast (NBMA). As
seções Próximo nó de BGP (Redes de multiacesso) e Próximo nó de BGP (NBMA) fornecem mais detalhes.
<9 Y <YYY4&YY
  5YY

Este exemplo mostra como o próximo nó comporta-se em uma rede de multiacesso com a Ethernet.

Suponhamos que RTC e RTD em AS300 executam OSPF. O RTC executa o BGP com o RTA. O RTC pode
alcançar a rede de 180.20.0.0 pelo 170.10.20.3. Quando o RTC envia uma atualização de BGP para o RTA
relacionado a 180.20.0.0, o RTC utiliza como próximo nó o 170.10.20.3. O RTC não utiliza seu próprio
endereço de IP, 170.10.20.2. O RTC utiliza este endereço porque a rede entre RTA, RTC, e RTD é uma rede
de multiacesso. O uso que o RTA faz do RTD como um próximo nó para alcançar 180.20.0.0 é mais sensato
do que o nó extra pelo RTC.

,"-YO RTC anuncia 180.20.0.0 para o RTA com um próximo nó 170.10.20.3.

Se o meio comum para RTA, RTC, e RTD não é multiacesso, mas sim NBMA, ocorrem mais complicações.

<9 Y <YYY4=a5YY

O meio comum aparece como uma nuvem no diagrama. Se o meio comum for uma frame relay ou qualquer
nuvem de NBMA, o comportamento exato será como se você estivesse conectado à Ethernet. O RTC
anuncia 180.20.0.0 para o RTA com um próximo de 170.10.20.3.

O problema é que o RTA não possui um circuito virtual permanente (PVC) direto para o RTD e não pode
alcançar o próximo nó. Neste caso, o roteamento falhará.
O comando 9*!
$ remedia esta situação.

 Y 9*!


$YY

Para situações com o próximo nó, como no exemplo Próximo nó de BGP (NBMA), é possível utilizar o
comando 9*!
$. A sintaxe é:

YYYYYYYYYYYY{  ÔipV
p

 pV{
 Y
YYYYYYYYYY
O comando 9*!
$ permite forçar o BGP a utilizar um endereço de IP específico como o próximo nó.

Para o exemplo Próximo nó do BGP (NBMA), esta configuração resolve o problema:

Y
Y
Y Y

 Y     Y Y Y

 Y     Y#  'YY
O RTC anuncia 180.20.0.0 com um próximo nó equivalente a 170.10.20.2.

 0YYYY

Neste diagrama, RTA e RTC executam eBGP. RTB e RTC executam eBGP. RTA e RTB executam algum
tipo de IGP, seja RIP, IGRP, ou outro protocolo. Por definição, atualizações do eBGP têm uma distância de
20, que é menos que as distâncias de IGP. As distâncias padrão são:

AY 120 para RIP


AY 100 para IGRP
AY 90 para EIGRP
AY 110 para OSPF

O RTA recebe atualizações sobre 160.10.0.0 por dois protocolos de roteamento:

AY eBGP com uma distância de 20


AY IGP com uma distância maior que 20

Por padrão, o BGP possui as seguintes distâncias:

AY Distância externa ² 20
AY Distância interna ² 200
AY Distância local ² 200

Mas você pode utilizar o comando    para alterar as distâncias padrão:

YYYYYYYYYYYY  {
V iV i
V
iV V iV
Y
YYYYYYYYYY
O RTA escolhe o eBGP pelo RTC por causa da distância mais curta.

Se desejar que o RTA aprenda sobre 160.10.0.0 pelo RTB (IGP), você tem duas opções:

AY Alterar a distância externa do eBGP ou a distância do IGP.

,"-YEssa alteração não é recomendada.

AY Utilize o backdoor do BGP.

O backdoor do BGP transforma a rota IGP na rota preferida.

Emita o comando /0YV

Y, 0.

A rede configurada é a que você deseja alcançar pelo IGP. Para o BGP, esta rede obtém o mesmo tratamento
que uma rede assinada localmente, exceto que atualizações do BGP não anunciam esta rede.

Y
Y
 Y Y
Y
-$Y     Y
Y
Y
Y Y

 Y Y Y Y
-$Y +    Y $YY
A rede 160.10.0.0 é tratada como uma entrada local, mas não é anunciada como uma entrada de rede
normal.

O RTA aprende 160.10.0.0 do RTB pelo EIGRP com distância 90. O RTA também aprende o endereço do
RTC pelo eBGP com distância 20. Normalmente, o eBGP é o preferido, mas por causa do comando
, 0, o EIGRP é o preferido.

 )YY
Antes de discutir a sincronização, observe este cenário. O RTC no AS300 envia atualizações sobre
170.10.0.0. RTA e RTB executam iBGP, portanto o RTB recebe a atualização e é capaz de alcançar
170.10.0.0 pelo próximo nó, 2.2.2.1. Lembre-se que o próximo nó é carregado pelo iBGP. Para alcançar o
próximo nó, o RTB deve enviar o tráfego para o RTE.

Suponhamos que o RTA não tenha redistribuído a rede 170.10.0.0 no IGP. Nesse ponto, o RTE não faz idéia
de que 170.10.0.0 sequer existe.

Se o RTB começar a anunciar para o AS400 que pode alcançar 170.10.0.0, tráfego que vem do RTD para o
RTB com destino 170.10.0.0 flui e descarrega no RTE.

A sincronização determina que, se o seu AS passa tráfego de outro AS para um terceiro AS, o BGP não deve
anunciar uma rota antes que todos os roteadores no seu AS aprenderam sobre a rota pelo IGP. O BGP espera
até que o IGP tenha propagado a rota dentro do AS. Depois, ele anuncia a rota para peers externos.

No exemplo nesta seção, o RTB espera escutar sobre 170.10.0.0 pelo IGP. Então, o RTB começa a enviar a
atualização ao RTD. É possível fazer o RTB acreditar que o IGP propagou as informações se você adicionar
no RTB uma rota estática que aponta para 170.10.0.0. Certifique-se de que outros roteadores podem
alcançar 170.10.0.0.

#,
Y  )YY

Em alguns casos, a sincronização não é necessária. Se você não passar tráfego de um AS diferente pelo seu
AS, pode desabilitar a sincronização. Também é possível desabilitar a sincronização se todos os roteadores
no seu AS executarem o BGP. A desabilitação deste recurso pode permitir que você carregue alguns
roteadores no seu IGP e que o BGP convirja mais rapidamente.

A desabilitação da sincronização não é automática. Se todos os seus roteadores no AS executarem o BGP e


você não executar o IGP, o roteador não tem como saber. Seu roteador aguarda indefinidamente por uma
atialização do IGP sobre certo roteador antes de enviar a rota a peers externos. Neste caso, é preciso
desabilitar a sincronização manualmente para que o roteamento funcione corretamente:

Y
Y Y
Y 23Y
,"-YCertifique-se de emitir o comando
Y !Y,+!YV

Ypara reiniciar a seção.


Y
Y
Y Y
-$Y     Y

 Y   Y Y% Y

 YY Y Y
Y 23Y
Y
YYYYYYYYYYYYYYY YY$#Y%% YY Y Y &  Y
YYY Y % Y Y
Y
Y
YY$'(Y  Y  YY$#Y)Y YY% *Y Y
Y
YYY
YYYYYYYYYYYYY
 Y
Y
Y% Y

 Y    Y Y Y
-$Y    Y
Y
Y
YYYY
Y Y
YYY-$Y     Y
YYY
 Y%Y Y Y
a ,YY! YY
O atributo de ponderação é um atributo definido pela Cisco. Este atributo utiliza ponderação para selecionar
um caminho melhor. A ponderação é atribuída localmente ao roteador. O valor só faz sentido para o
roteador específico. O valor não é propagado ou carregado por nenhuma das atualizações de rota. O peso
pode ser um número de 0 a 65,535. Caminhos originados pelo roteador têm um peso de 32,768 por padrão e
outros caminhos pesam 0.

Rotas com mesmo valor de ponderação têm preferência quando existem diversas rotas para o mesmo
destino. Veja o exemplo nessa seção. O RTA aprendeu sobre a rede 175.10.0.0 do AS4. O RTA propaga a
atualização para o RTC. O RTB também aprendeu sobre a rede 175.10.0.0 do AS4. O RTB propaga a
atualização para o RTC. O RTC agora possui duas maneiras de alcançar 175.10.0.0 e tem que decidir o
caminho que seguir. Se definir a ponderação das atualizações no RTC que vêm do RTA para que seja maior
do que a ponderação das atualizações que vêm do RTB, você forçará o RTC a utilizar o RTA como próximo
nó para alcançar 175.10.0.0. Diversos métodos de alcançar esse conjunto de ponderações:

AY Utilize o comando  +*,.


Y  +*,Y> V

Y?Y   @Y/ +*Y Y


AY Utilize listsa de acesso AS_PATH.
Y !Y!*Y 
YV 


{Y>! Y?Y 8@YV
V  

{Y  +*,Y
 V

Y$

YV 


{Y/ +*Y Y
AY Utilize mapas de rotas.
AY Y
AY Y
Y Y
AY 
 Y    Y Y Y
AY 
 Y    Y-
Y Y
AY Y
AY YYYYYYYYYYYYYYYYYYYYY YY
 Y
YY
Y Y$Y Y
+)YY
AY YYYYYYYYYYYYYYYYYYY
AY 
 YY Y Y
AY 
 YY-
Y Y
AY Y
AY YYYYYYYYYYYYYYYYYYYYY YY
 Y
YY
Y Y$#Y Y
+)YY
AY YYYYYYYYYYYYYYYYYYY
YYYYYYYYYYYYYYYY
O RTA, que possui um valor de ponderação maior, possui preferência como o próximo nó.

É possível alcançar o mesmo resultado com as listas de filtro e AS_PATH do IP.

Y
Y
Y Y

 Y    Y Y Y

 Y    Y' YY-
Y Y

 YY Y Y

 YY' Y+Y-
Y Y
Y
 Y  Y  YY Y4 5Y
Y
YYYYYYYYYYYYYYY YY
 Y  YY% *YY
YYYYYYYYYYYYY
 Y  Y  Y+Y Y4 5Y
YY
Também é possível alcançar o mesmo resultado com a utilização de mapas de rotas.

Y
Y
Y Y

 Y    Y Y Y

 Y    Y Y -
YY

 YY Y Y

 YY Y -
YY
Y
 Y  Y  YY Y4 5Y
Y
Y
 Y -
Y Y Y
Y  YY
Y-
Y Y
Y
YYYYYYYYYYYYYYY Y,  
Y% Y  Y Y % Y
Y
% 
Y Y Y(Y%Y % Y Y(YY

+)YY
YYYYYYYYYYYYY
Y
 Y -
Y Y Y
YYY Y-
Y Y
Y
YYYYYYYYYYYYYYY Y,  
Y
Y% YY
+)
Y
YYYYYYYYYYYYY
YYYYYYYYYY
a ,YY!$A Y
 
YY

Preferência local é uma indicação ao AS sobre que caminho tem preferência para sair do AS para alcançar
certa rede. Um caminho com preferência local mais alta é preferido. O valor padrão da preferência local é
100.

Diferente do atributo de ponderação, que só é relevante para o roteador local, a a preferência local é um
atributo que os roteadores trocam no mesmo AS.

É possível configurar a preferência local com a emissão do comando ,+!Y$


Y
 
!$ YëVY.
Também é possível configurar a preferência local com mapas de rotas, como demonstrado no exemplo desta
seção:

O comando ,+!Y$
Y
 
!$  configura a preferência nas atualizações de fora do roteador que
vão para peers no mesmo AS. No diagrama desta seção, o AS256 recebe atualizações sobre 170.10.0.0 de
dois lados diferentes da organização. A preferência local ajuda você a determinar de que lado sair do AS256
para alcançar aquela rede. Suponhamos que o RTD seja a preferência do ponto de saída. Esta configuração
detetermina a preferência local para atualizações que vão do AS300 para o 200 e para atualizações que vão
do AS100 para o 150:

Y
Y
Y+Y

 Y    Y Y Y

 Y *  Y Y+Y

Y'Y 'Y  Y
Y
 Y
Y
Y+Y

 Y%Y Y Y

 Y *   Y Y+Y

Y'Y 'Y Y
Nesta configuração, o RTC determina a preferência local de todas as atualizações como 150. O mesmo RTD
determina a preferência local de todas as atualizações como 200. Há uma troca de preferências locais no
AS256. Portanto, tanto o RTC quanto o RTD percebem que a rede 170.10.0.0 possui uma preferência local
mais alta quando as atualizações vêm do AS300 em vez do AS100. Todo o tráfego no AS256 que tenha
aquela rede como destino transmite com o RTD como ponto d saída.

A utilização de mapas de rota fornece mais flexibilidade. No exemplo nesta seção, todas as atualizações
recebidas pelo RTD estão marcadas com a preferência local 200 quando chegam no RTD. Atualizações que
vêm do AS34 também estão marcadas com a preferência local 200. Esta marca pode ser desnecessária. Por
esta razão, é possível utilizar mapas de rotas para especificar estas atualizações específicas que precisam ser
marcadas com uma preferência local específica. Segue um exemplo:

 Y
Y
Y+Y

 Y%Y Y Y

 Y%Y Y YY

 Y *   Y Y+Y
Y
 Y  Y  YY Y4 5Y
Y
Y
 Y Y Y Y
Y  YY
Y 'Y Y
Y
 Y Y Y Y
Y 'Y  YY
Com esta configuração, qualquer atualização que venha do AS300 possui uma preferência local de 200.
Quaisquer outras atualizações, como as que vêm do AS34, possuem um valor de 150:

a ,YY YY


O atributo de métrica também é chamado de MULTI_EXIT_DISCRIMINATOR, MED (BGP4), ou
INTER_AS (BGP3). O atributo é uma dica para vizinhos externos sobre a preferência de caminho em um
AS. O atributo fornece uma maneira dinâmica de influenciar outro AS de modo a alcançar certa rota quando
houver diversos pontos de entrada naquele AS. Um valor métrico menor é preferido.

Diferente de preferência local, a métrica é trocada entre ASs. Uma métrica é carregada em um AS, mas não
sai do AS. Quando uma atualização entra no AS com certa métrica, tal métrica é utilizada para tomar
decisões dentro do AS. Quando a mesma atualização passa para um terceiro AS, a métrica volta a 0. O
diagrama nesta seção mostra o conjunto de métricas. O valor padrão da métrica é 0.

A não ser que um roteador receba outras direções, ele compara métricas de caminhos de vizinhos no mesmo
AS. Para que o roteador compare métricas de vizinhos que vêm de Ass diferentes, é preciso emitir o
comando de configuração especial ,+!Y
/8 ! no roteador.

,"-YHá dois comandos de configuração de BGP que podem influenciar a seleção de caminho com
base no discriminador de múltiplas saídas (MED). Os comandos são o ,+!Y   e o ,+!Y

/8 !. Uma emissão do comando ,+!Y   garante a comparação da
variável MED em escolha de rotas quando peers diferentes anunciam no mesmo AS. Uma emissão do
comando ,+!Y
/8 ! garante a comparação do MED para caminhos de vizinhos em ASs
diferentes. O comando ,+!Y
/8 ! é útil quando fornecedores ou empreendimentos de
serviço múltiplo concordam sobre uma política uniforme para a configuração de MED. Consulte Como o
comando bgp deterministic-med defere do comando bgp always-compare-med para entender como esses
comandos influenciam a seleção de caminhos do BGP.

No diagrama desta seção, o AS100 recebe informações sobre a rede 180.10.0.0 por três roteadores
diferentes. RTC, RTD e RTB. RTC e RTD estão no AS300, e o RTB está no AS400.

Suponhamos que você tenha configurado a métrica que vai do RTC ao 120, a métrica que vai do RTD ao
200 e a métrica que vai do RTB ao 50. Por padrão, um roteador compara as métricas que vêm de vizinhos no
mesmo AS. Portanto, o RTA pode comparar somente a métrica que vem do RTC à métrica que vem do
RTD. O RTA escolhe o RTC como o melhor próximo nó, pois 120 é menos que 200. Ao receber uma
atualização do RTB com étrica 50, o RTA não pode comparar a métrica a 120 porque o RTC e o RTB estão
em ASs diferentes. O RTA deve escolher com base em alguns outros atributos.

Para forçar o RTA a comparar as métricas, você deve emitir o comando ,+!Y
/8 ! no
RTA. Estas configurações ilustram o processo:

Y
YYYY
Y Y
YYY
 Y Y Y Y
YYY
 YY Y Y
YYY
 Y%%%Y Y% Y
YYYY
Y
Y
YYYY
Y Y
YYY
 YY Y Y
YYY
 YY Y YY
YYY
 Y   Y Y Y
Y
 Y Y Y Y
YYY YY  Y
Y
 Y
YYYY
Y Y
YYY
 YY Y Y
YYY
 YY Y YY
YYY
 Y    Y Y Y
Y
 Y Y Y Y
YYY YY Y
Y
Y
YYYY
Y% Y
YYY
 Y%%%%Y Y Y
YYY
 Y%%%%Y Y YY
Y
 Y Y Y Y
YYY YY Y
Com estas configurações, o RTA escolhe o RTC como próximo nó, levando em consideração o fato de que
todos os outros atributos são iguais. Para incluir o RTB na comparação de métricas , é preciso configurar o
RTA da seguinte maneira:

Y
Y
Y Y

 Y Y Y Y

 YY Y Y

 Y%%%Y Y% Y

Y-2  Y
Neste caso, o RTA escolhe o RTB como o melhor próximo nó para alcançar a rede 180.10.0.0.

Também é possível configurar métricas durante a redistribuição de rotas no BGP se você emitir o comando
$
 Y{Y.

Suponhamos que, no exemplo desta seção, o RTB injete uma rede por informações estáticas no AS100. Eis
aqui a configuração:

Y
Y
Y% Y
  Y Y
'Y Y
Y
 YY *    Y  YY Y
Y
YYYYYYYYYYYYYYY YY- .Y%Y  YY$#Y " Y
/Y%Y Y0
% YY
YYYYYYYYYYYYY
YYYYYYYYYY
a ,YY  YY

O atributo de comunidade é opcional e transitivo com um intervalo de 0 a 4,294,967,200. O atributo de


comunidade é um meio de agrupar destinos em uma certa comunidade e aplicar decisões de roteamento de
acordo com essas comunidades. As decisões de roteamento são aceitar, preferir e redistribuir, dentre outras.

É possível utilizar mapas de rotas para definir os atributos de comunidade. O comando  do mapa de rotas
possui essa sintaxe:

YYYYYYYYYYYY 

{  i  


 
 iY
YYYYYYYYYY
Algumas comunidades conhecidas predefinidas para serem utilizadas neste comando são:

AY 9! ² Não anunciar para peers de eBGP. Mantenha esta rota dentro de um AS.
AY "  ² Não anunciar esta rota a nenhum peer, interno ou externo.
AY   ² Anunciar esta rota à comunidade da Internet. Qualquer roteador pertence a esta rota.
AY
 
 ² Utilizar cenários de confederação para impedir a transmissão de pacotes para fora do AS
local.

Eis dois exemplos de mapas de rotas que definem a comunidade:

AY  Y2 Y
AY Y Y Y Y
AY Y2Yë Y
ou

AY  Y 2Y
AY Y  Y Y
AY Y2Y YëYY
Se você não configurar a palavra-chave de   , 200 substituirá qualquer comunidade antiga já
existente. Se você utilizar a palavra-chave de   , ocorrerá um acréscimo de 200 à comunidade.
Mesmo se você definir o atributo de comunidade, este atributo não transmitirá aos vizinhos por padrão. Para
enviar o atributo a um vizinho, você deve utilizar este comando:

YYYYYYYYYYYY{  ÔipV
p

 pV {


{ Y
YYYYYYYYYY
Segue um exemplo:

Y
Y
Y Y

 YY Y Y

 YY 2Y

 YY Y 2YY
Nas versões 12.0 e posteriores do Cisco IOS Software, é possível configurar comunidades em três formatos
diferentes: decimal, hexadecimal e AA:NN. Por padrão, o Cisco IOS Software utiliza o formato decimal
mais antigo. Para cofigurar e exibir como AA:NN, emita o comando de configuração global !Y,+!
 8Y /$. A primeira parte de AA:NN representa o número de AS e a segunda representa
um número de 2 bytes.

Segue um exemplo:

Sem o comando !Y,+!  8Y /$ em configuração global, uma emissão do comando */Y
!Y,+!YB323232 exibe o valor do atributo de comando em formato decimal. Neste exemplo, o valor do atributo
de comunidade aparece como ++ .

Y  ! ! !Y
 Y
Y Y2Y'Y+   6*!Yë YY
 (Y7 Yë !Y  Y !Y Y '  

 8Y
YY9Yë YY2Y Y
YY Y
YYYY    Y'Y    Y7    8Y
YYYYYY0
Y !YY !Y 'Y !Yë!Y
#!Y  Y
YYYYYY"
{ #$$%&!Y
YYYYYYYYYY
Agora, emita o comando !Y,+!  8Y /$ globalmente neste roteador.

Y {ÔÔ
{ Y
cY'
Y !YY YYYcY-Y
9)6:Y
7'
8Y 

{ {  Ô
Y
7'
8YY
YYYYYYYYYY
Com o comando de configuração global !Y,+!  8Y /$Y, o valor de comunidade sera
exibido no formato AA:NN. O valor aparecerá como ( na saída do comando */Y !Y,+!YB323232
neste exemplo:

Y  ! ! !Y
 Y
Y Y2Y'Y+   6*!Yë YY
 (Y7 Yë !Y  Y !Y Y '  

 8Y
YY9Yë YY2Y Y
YY Y
YYYY    Y'Y    Y7    8Y
YYYYYY0
Y !YY !Y 'Y !Yë!Y
#!Y  Y
YYYYYY"
{ #'!!#&!Y
YYYYYYYYYY
YY YYYYY

^
+YYYY

Um número de diferentes métodos de filtro permite que você controle o envio e recebimento de atualizações
do BGP. É possível filtrar as atualizações de BGP com informações de rotas como base ou com informaões
de caminho ou comunidades como base. Todos os métodos alcançam o mesmo resultado. A escolha de um
ou outro método depende da configuração específica da rede.

^
+YYY

Para restringir as informações de roteamento que o roteador aprende ou anuncia, é possível filtrar o BGP
utilizando atualizações de rotas para formar um vizinho em particular. Você defini uma lista de acesso e a
aplica às atualizações para ou de um vizinho. Emita este comando no modo de configuração do roteador:
YYYYYYYYYYYY{  ÔipV
p

 pV
 Ô  Vi  
{ Y
YYYYYYYYYY
Neste exemplo, o RTB origina a rede 160.10.0.0 e envia a atualização para o RTC. Se o RTC desejar parar a
propagação de atualizações ao AS100, você deve definir uma lista de acesso para filtrar as atualizações e
aplicar a lista de acesso durante a comunicação com RTA:

Y
Y
Y Y
-$Y     Y

 YY Y Y

 YY Y Y

 YY   Y YY
Y
  Y Y2Y +    Y  Y
Y
  Y Y Y    YY
Y
YYYYYYYYYYYYYYY Y1

Y Y Y  . +2 Y Y

  Y&
YY344Y
YYYYYYYYYYYYY
YYYYYYYYYY
A utilização de listas de acesso é complicada ao lidar com super-redes que podem causar alguns conflitos.

Suponhamos que, no exemplo desta seção, o RTB possua sub-redes diferentes de160.10.x.x. Seu objetivo é
filtrar atualizações e anunciar somente 160.0.0.0/8.

,"-YA notação /8 que você está utilizando 8 bits de máscara de sub-rede, que começa na extrema
esquerda do endereço de IP. Este endereço equivale a 1600.0.0.255.0.0.0.

O comando  
YY! YB2323232Y2333 permite 160.0.0.0/8, 160.0.0.0/9, e assim por
diante. Para restringir a atualização para apenas 160.0.0.0/8, é preciso utilizar uma lista de acesso estendida
neste formato:

YYYYYYYYYYYY   '!'Ô


'! ! ! !
! &$$ &$$ &$$&$$ ! ! !! ! ! ! Y
YYYYYYYYYY
Esta lista permite somente 160.0.0.0/8.

Consulte Como bloquear uma ou mais redes de um peer de BGP para obter amostras de configuração sobre
como filtrar redes de peers do BGP. O método utiliza o comando   ,
 com listas de controle de
acesso (ACLs) estendidas e padrão, assim como filtro de listas de prefixo.

^
+YY  *YY

Outro tipo de filtragem é a filtragem de caminho.


É possível especificar uma lista de acesso para atualizações entrando ou saindo com a utilização das
informações de caminhos de AS do BGP. No diagrama desta seção, é possível bloquear atualizações sobre
160.10.0.0 para que elas não vão para o AS100. Para bloquear as atualizações, defina uma lista de acesso no
RTC que impeça a transmissão para o AS100 de quaisquer atualizações originadas do AS200. Emita estes
comandos:

YYYYYYYYYYYY      Vi  



Ô
{ V
 V
p
i
Y
YYYYYYYYYY
YYYYYYYYYYYY{  ÔipV
p

 pV
Ô  Vi  
{ Y
YYYYYYYYYY
Este exemplo impede o RTC de enviar atualizações sobre 160.10.0.0 para o RTA:

Y
Y
Y Y

 YY Y Y

 YY Y Y

 YY' Y YY
Y
YYYYYYYYYYYYYYY YYY0YY5
Y Y Y Y % Y
& 4Y
YYYYYYYYYYYYY
 Y  Y  Y Y2Y4 5Y
 Y  Y  Y Y Y;Y
O comando  
Y neste exemplo força a negação de quaisquer atualizações com informações de
caminho que comecem com 200 e terminem com 200. O 4 5 no comando é uma "expressão regular", na
qual 4 significa "iniciar com" e 5 significa "finalizar com". Como o RTB envia atualizações sobre
160.10.0.0 com informações de caminho que comecem com 200 e terminem com 200, as atualizações
correspondem à lista de acesso. A lista de acesso nega estas atualizações.

O ; é outra expressão regular, na qual o  significa "qualquer caractere" e o ; significa "a repetição daquele
caractere". Portanto, ; representa qualquer informação de caminho, que é necessária para permitir a
transmissão de todas as outras atualizações.

O que acontece se, em vez de utilizar 4 5 , você utilizar 4 ? Com um AS400, como no diagrama desta
seção, atualizações originadas do AS400 possuem informações de caminho do formulário (200, 400). Nesta
informação de caminho, 200 é o primeiro e 400 é o último. Essas atualizações correspondem à lista de
acesso. 4 porque as informações de caminho começam com 200. A lista de acesso impede a transmissão
destas atualizações para o RTA, que não é o requisito.

Para verificar se você implementou a expressão regular correta, emita o comando */Y !Y,+!Y+9!Y
V  

{Y. Este comando exibe todos os caminhos que corresponderam à configuração da


expressão regular.

9!Y+
YYa YY

Esta seção explica a critação de uma expressão regular.

Uma expressão regular é um padrão para corresponder contra uma série de entrada. Ao construir uma
expressão regular, você especifica uma série à qual a entrada deve corresponder. No caso do BGP, você
especifica uma série que consiste de informações de caminho às quais a entrada deve corresponder.

No exemplo da seção Filtragem de caminho, você especificou a série 4 5. Você queria informações de
caminho que em dentro de atualizações para corresponder à série de modo a tomar uma decisão.

Uma expressão regular compreende:

AY a
 

Alcance é uma seqüência de caracteres entre colchetes à direita e à esquerda. Um exemplo é


@ < .

AY 8

Um átomo é um único caractere. Estes é um exemplo:

Y
Y O  corresponde a um único caractere.

4Y
Y O 4 corresponde ao início da série de entrada.

5Y
Y O 5 corresponde ao fim da série de entrada.

=Y
Y O = corresponde ao caractere.
Y
Y O  corresponde a uma vírgula (!colchete esquerdo (>), right brace (?), o início de uma série
de entrada, o fim de uma série de entrada, ou um espaço.
AY 

Uma parte é um dos símbolos que seguem um átomo:

;Y
Y O ; corresponde a 0 ou mais seqüências do átomo.

@Y
Y O @ corresponde a 1 ou mais seqüências do átomo.

GY
Y O G corresponde ao átomo ou à série nula.
AY ^


Uma filial é 0 ou mais partes concatenadas.

Aqui estão alguns exemplos de expressões regulares:

;Y
AY Esta expressão indica qualquer ocorrência da letra "a", que inclui nenhuma.

@Y
AY Esta expressão indica que ao menos uma ocorrência da letra "a" deve estar presente.

 GY
AY Esta expressão corresponde a "aa" ou "aba".

D DY
AY Esta expressão significa pelo AS100.

D 5Y
AY Esta expressão indica uma origem do AS100.

4 Y;Y
AY Esta expressão indica uma transmissão do AS100.

45Y
AY Esta expressão indica uma origem deste AS.

Consulte Utilizando expressões regulares no BGP para exemplos de configurações de filtragem de


expressões regulares.

^
+YY  YYY

Este documento cobriu filtragem de rota e filtragem de caminho AS. Outro método é a filtragem de
comunidade. A seção Atributo de comunidade discute comunidades e esta seção fornece alguns exemplos de
como utilizar comunidades.

Neste exemplo, você deseja que o RTB defina o atributo de comunidade para rotas do BGP que o RTB
anuncia, de modo que o RTC não propague essas rotas para peers externos. Utilize o atributo de comunidade
9!.

Y
Y
Y Y
-$Y +    Y

 Y Y Y Y

 Y Y 2Y

 Y Y Y 2YY
Y
 Y 2Y
Y Y Y Y
Y2Y# Y
Y
  Y Y Y    YYY
,"-YEste exemplo utilizaa o comando !Y  8 para configurar a comunidade
como 9!Y.

,"-YO comando  +*,Y   8 é necessário para enviar este atributo para o RTC.

Quando o RTC recebe as atualizações com o atributo NO_EXPORT, ele não propaga as atualizações para o
RTA do peer externo.

Neste exemplo, o RTB configurou o atributo de comunidade como   YY22Y22Y. Esta ação
adiciona o valor 100 200 para qualquer valor de comunidade existente antes da transmissão para o RTC.

Y
YYYY
Y Y
YYY-$Y +    Y
YYY
 Y Y Y Y
YYY
 Y Y 2Y
YYY
 Y Y Y 2YY
Y
 Y 2Y
Y Y YY
Y2Y Y YëY
Y
  YY Y    YYY
Uma lista de comunidades é um grupo de comunidades que você utiliza em uma cláusula !  de
um mapa de rotas. A lista de comunidades permite que você filtre ou configure atributos com diferentes
listas de números de comunidades como base.

YYYYYYYYYYYY

{   ii  



Ô
{  i  

Y
YYYYYYYYYY
Por exemplo, é possível dfinir este mapa de rotas como  *   8Y.

 Y2Y
Y2Y Y
Y
YYYYYYYYYYYYYYY YY5
Y Y Y Y% Y0YY
YYYYYYYYYYYYY
Y-
Y Y
 Y2 Y Y Y Y Y
Y
YYYYYYYYYYYYYYY YY5
Y Y Y Y% Y0Y
!Y
YYYYYYYYYYYYY
YYYYYYYYYY
É possível utilizar a lista de comunidades para filtrar ou configurar alguns parâmetros, como ponderação e
métrica, em certas atualizações tendo o valor de comunidade como base. No segundo exemplo desta seção, o
RTB envia atualizaões ao RTC com uma comunidade de 100 200. Se o RTC desejar definir a ponderação
tendo estes valore como base, você pode:

Y
Y
Y Y

 YY Y Y

 YY Y$2YY
Y
 Y$2Y Y Y
Y2Y Y
Y-
Y Y
Y
 Y$2Y Y Y
Y2YY#Y
Y-
Y Y
Y
 Y$2Y Y Y
Y2YY
Y
 Y2 Y Y Y Y
 Y2 YY Y Y
 Y2 YY YYY
Neste exemplo, qualquer rota que possua 100 no atributo de comunidade corresponde à lista 1. A
ponderação desta rota está configurada para 20. Qualquer rota que possua apenas 200 como comunidade
corresponde à lista 2 e possui uma ponderação de 20. A palavra-chave 9 determina que a comunidade
consiste de apenas 200 e nada mais. A última lista de comunidades está aqui para garantir que outras
atualizações não sejam descartadas. Lembre-se que qualquer coisa que não corresponda é descartada, por
padrão. A palavra-chave   indica todas as rotas porque todas elas são membros da comunidade da
internet.

Consulte Utilizando valores de comunidade de BGP para controlar a política de roteamento em uma rede de
provedor upstream para obter mais informações.

C ) *YYYY!YYYY
É possível utilizar o comando  +*, em conjunção com mapas de rotas para filtyrar ou configurar
parâmetros em atualizações chegando ou saindo.

Mapas de rota associados com a instrução  +*, não possuem efeito em atualizações que estão chegando
ao corresponde-las com os endereços de IP:

YYYYYYYYYYYY{  ÔipV
Ô 

 VpV
Y
YYYYYYYYYY
Suponhamos que, no diagrama desta seção, você deseje que o RTC aprenda do AS200 sobre redes locais ao
AS200 e nada mais. Além disso, você deseja configurar a ponderação nas rotas aceitas para 20. Utilize uma
combinação de listas de acesso  +*, e !*:

Y
YYYY
Y Y
YYY-$Y     Y
YYY
 YY Y Y
YYY
 YY Y  YY
Y
 Y  Y
Y  Y Y
Y-
Y Y
Y
 Y  Y  Y Y Y4 5YY
Quaisquer atualizações que originem do AS200 possuem informações de caminho que começam com 200 e
terminam com 200. Essas atualizações são permitidas. Quaisquer outras atualizações são descartadas.

Suponhamos que você deseje:

AY Uma aceitação de atualizações que originam do AS200 e possuem ponderação 20


AY O descarte de atualizações que originam do AS400
AY Uma ponderação de 10 para outras atualizações
AY Y
AY Y
Y Y
AY -$Y     Y
AY 
 YY Y Y
AY 
 YY Y  YY
AY Y
AY  Y  Y Y Y
AY Y  Y Y
AY Y-
Y Y
AY Y
AY  Y  Y Y Y
AY Y  YY
AY Y-
Y Y
AY Y
AY  Y  Y  Y Y Y4 5Y
 Y  Y  YY Y4 Y+ Y;Y
Esta instrução define uma ponderação de 20 para atualizações locais do AS200. A instrução
também configura uma ponderação de 10 para atualizações atrás do AS400 e descarta atualizações
provenientes do AS400.

'
)YY YY!*Y!! Y

Em algumas situações, você deve manipular as informações de caminho para manipular o processo de
decisão do BGP. O comandoque você utiliza com um mapa de roteamento é o:

YYYYYYYYYYYY    Ô{VpV


VpV
Y
YYYYYYYYYY
Suponhamos que, no diagrama da seção Vizinhos de BGP e mapas de rotas, o RTC anuncia sua própria rede
170.10.0.0 para dois ASs diferentes, o AS100 e o AS200. Quando as informações são propagadas para o
AS600, os roteadores no AS600 possuem informações de alcançabilidade sobre 150.10.0.0 por duas rotas
diferentes. A primeira rota é pelo AS100 com o caminho (100, 300) e a segunda é pelo AS400 com o
caminho (400, 200, 300). Se todos os outros atributos forem os mesmos, o AS600 escolhe o caminho mais
curto, o da rota pelo AS100.

O AS300 recebe todo o tráfego pelo AS100. Se desejar influenciar esta decisão do fim do AS300, você pode
fazer o caminho pelo AS100 parecer maior do que o caminho que passa pelo AS400. Você poderá fazer isso
se anexar números do AS às informações de caminho existentes que é anunciada ao AS100. Uma prática
comum é repetir seu próprio número de AS da seguinte forma:

Y
Y
Y Y
-$Y     Y

 YY Y Y

 YY Y"c AYY
Y
 Y"c AY
Y  Y  Y Y Y
Por causa desta configuração, o AS600 recebe atualizações sobre 170.10.0.0 pelo AS100 com informações
de caminho do: (100, 300, 300, 300). Estas informações de caminho são maiores do que a (400, 200, 300)
que o AS600 recebeu do AS400.

!YY!YYYY
Um grupo de peers de BGP é um grupo de vizinhos de BGP com algumas das mesmas políticas de
atualização. Mapas de rotas, listas de distribuição e listas de filtros normalmente configuram políticas de
atualização. Não é possível configurar as mesmas políticas para cada vizinho separad; mas você pode
degfinir um nome de grupo de peer e atribuir essas políticas a preparar para o grupo.

Membros de seu próprio grupo de peers herdam todas as opções de configuração do grupo de peers. É
possível configurar membros para cancelar estas opções se elas não afetarem atualizações externas. Só é
possível cancelar opções configuradas como internas.

Para definir um grupo de peers, emita este comando:

YYYYYYYYYYYY{  Ôp

 pVÔ Ô Y
YYYYYYYYYY
Este exemplo aplica-se a grupos de peer de vizinhos internos e externos do BGP:

Y
YYYY
Y Y
YYY
 Y Y 
 Y
YYY
 Y Y Y Y
YYY
 Y Y Y"c,c YY
YYY
 Y Y' Y YY
YYY
 Y Y' YYY
YYY
 YY 
 Y Y
YYY
 Y++Y 
 Y Y
YYY
 YY 
 Y Y
YYY
 YY' YYY
Esta configuração define um grupo de peers chamado  
!. A configuração define algumas
políticas para o grupo, como um mapa de rotas   & para definir a métrica como 5 e duas
diferentes listas de filtro, 1 e 2. A configuração aplica o grupo de peers a todos os vizinhos internos, o RTE,
o RTF, e o RTG. Além disso, a configuração define uma lista de filtro separada 3 para RTE vizinho. A lista
de filtros cancela a lista de filtros 2 dentro do grupo de peers.

,"-Y <YY!D"
Y  
Y!%YY$Y
)%Y  3

Agora, observe como utilizar grupos de peers com vizinhos externos. Com o mesmo diagrama desta seção,
vocÇe configura o RTC com um grupo de peers 9 
! e aplica o grupo de peers aos vizinhos
externos.

Y
YYYY
Y Y
YYY
 Y# Y 
 Y
YYY
 Y# Y Y"c,c Y
YYY
 Y# Y' Y YY
YYY
 Y# Y' YYY
YYY
 YY Y Y
YYY
 YY 
 Y# Y
YYY
 Y%%%Y Y+ Y
YYY
 Y%%%Y 
 Y# Y
YYY
 Y   Y Y Y
YYY
 Y   Y 
 Y# Y
YYY
 Y   Y' YYY
,"-YNestas configurações, você define as instruções  fora do grupo de peers porque deve
definir ASs externos diferentes. Além disso, você pode cancelar as atualizações internas do vizinho 1.1.1.2
com a atribuição da lista de filtros 3.

Para obter mais informações sobre grupos de peers, consulte Grupos de peers do BGP.

,"-YNa versão 12.0(24)S do Cisco IOS Software, a Cisco apresentou o recurso Grupos de peers de
atualização dinâmica do BGP. Esse recurso está disponível em versões posteriores do Cisco IOS Software
também. O recurso introduz um novo algoritmo que calcula e otimiza dinamicamente grupos de atualizações
de vizinhos que compartilham as memas políticas externas. Estes vizinhos podem compartilhar as mesmas
mensagens de atualização. Em versões anteriores do Cisco IOS Software, o grupo de mensagens de
atualização do BGP era à base de configurações de grupos de peers. Este método de atualizações de grupos é
limitado a políticas externas e configurações de sessões específicas. O recurso Grupo de peers de atualização
dinâmica do BGP réplicas de grupos de atualizações de configurações de grupos de peers. A separação
melhora o tempo de convergência e a flexibilidade da configuração do vizinho. Consulte Grupos de peers de
atualização dinâmica do BGP para obter mais detalhes.

YY YYYYY

 Y++YYY#&YY
Um dos principais melhorias do BGP4 sobre o BGP3 é o roteamento entre domínios sem classe (CIDR).
CIDR ou super-rede é um novo modo de ver endereços de IP. Como o CIDR, não há noção de classes, como
classe A, B, ou C. Por exemplo, a rede 192.213.0.0 já foi uma rede ilegal de classe C. Agora, a rede é uma
super-rede legal, 192.213.0.0/16. O "16" representa o número de bits na máscara da super-rede, quando você
conta a partir da extrema esquerda do endereço de IP. Esta representação é semelhante a 192.213.0.0
255.255.0.0.

Você utiliza agregados para minimizar o tamanho de tabelas de roteamento. Agregação é o processo que
combina as características de várias rotas diferentes de tal modo que é possível anunciar uma única rota.
Neste exemplo, o RTB gera a rede 160.10.0.0. Você configura o RTC para propagar uma super-rede da rota
160.0.0.0 para o RTA:

Y
Y
Y Y

 Y Y Y Y
-$Y +    Y
Y
 Y
Y
Y Y

 YY Y Y

 YY Y Y
-$Y     Y



 Y +    Y   YY
O RTC propaga o endereço agregado 160.0.0.0 para o RTA.

 Y++YY

Existe uma ampla faixa de comandos agregados. Você deve entender como cada um funciona para obter o
comportamento de agregação desejado.

O primeiro comando é o do exemplo na seção Endereços agregados e de CIDR:

YYYYYYYYYYYY Ô  Ô V


V
Y
YYYYYYYYYY
Este comando anuncia a rota de prefixo e todas as rotas mais específicas. O comando +++Y
B2323232 propaga uma rede adicional 160.0.0.0, mas não impede a propagação de 160.10.0.0 para o RTA. O
resultado é a propagação de ambas as redes 160.0.0.0 e 160.10.0.0 para o RTA, que é o anúncio da rota de
prefixo e da mais específia.

,"-YVocê não pode agregar um endereço se não possuir uma rota mais específica do endereço na
tabela de roteamento do BGP.

Por exemplo, o RTB não pode gerar um agregado para 160.0.0.0 se não possuir uma entrada mais específica
de 160.0.0.0 na tabela do BGP. A infjeção de uma rota mais específica à tabela do BGP é possível. A
injeção da rota pode ocorrer por:

AY Atualizações de entrada de outros ASs


AY Redistribuição de um IGP ou estática no BGP
AY O comando /0, por exemplo, /0YB2323232

Se desejar que o RTC propague somente a rede 160.0.0.0 e  a rota mais específica, emita este comando:

YYYYYYYYYYYY Ô  Ô V


 V 

Ô { Y
YYYYYYYYYY
Este comando anuncia somente o prefixo. O comando suprime todas as rotas mais específicas.

O comando +++YB2323232Y323232Y8
8 propaga a rede 160.0.0.0 e suprime a rota mais
específica 160.10.0.0.

,"-YSe você agregar uma rede que injetou no BGP pelas instruções /0, a entrada de rede
sempre injetará atualizações no BGP. Esta injeção ocorre mesmo com a utilização do comando +++Y
8
8. O exemplo na seção Exemplo de CIDR 1 discute essa situação.

YYYYYYYYYYYY Ô  Ô V


V Y
YYYYYYYYYY
Este comando anuncia a rota de prefixo e as rotas mais específicas. Mas o comando inclui informações de
 nas informações de caminho das atualizações de roteamento.

YYYYYYYYYYYY Ô '&( ! ! !&$$ ! ! ! Y


YYYYYYYYYY
A seção Exemplo de CIDR 2 (as-set) discute este comando.

Se deesejar suprimir rotas mais específicas ao fazer a agregação, defina um mapa de rotas e aplique-o aos
agregados. A ação permite que você seja seletivo quanto a que rotas mais específicas suprimir.

YYYYYYYYYYYY Ô  Ô V


V Ô

VpV
Y
YYYYYYYYYY
Este comando anuncia a rota de prefixo e as rotas mais específicas. Mas o comando suprime anúncios com
base em um mapa de rotas. Suponhamos que, com o diagrama na seção Endereços agregados e de CIDR,
você deseje agregar 160.0.0.0, suprimir a rota mais específica 160.20.0.0 e permitir a propagação de
160.10.0.0. Utilize este mapa de rotas:

 YAcBY Y Y


Y Y Y Y
Y
  Y Y Y +    Y  Y
  Y Y2Y    YY
Por definição do !YY %, há uma supressão das atualizações de qualquer pacote que o limite de
acesso permitir.

Então, aplique o mapa de rotas às instruções +++.

Y
Y
Y Y

 YY Y Y

 YY Y Y

 YY Y Y
-$Y     Y



 Y +    Y   Y    YAcBYY
Aqui está outra variação:

YYYYYYYYYYYY Ô  Ô V


V Ô

VpV
Y
YYYYYYYYYY
Este comando permite que você configure os atributos, como a métrica e o tempo de envio dos agregados.
Para configurar a origem dos agregados para IGP, aplique este mapa de rotas ao comando +++Y
 ,!:

 Y"c,c Y


Y
Y
Y
Y



 Y +    Y   Y  Y
"c0 9Y
Para obter mais informações, consulte Entendendo agregação de rotas no BGP.

9!
YY#&YYY
Requisição: Permite que o RTB anuncie o prefixo 160.0.0.0 e suprima todas as rotas mais específicas. O
problema com este requisito é que a rede 160.10.0.0 é local do AS200, o que significa que o AS200 é o
originador de 160.10.0.0. Não é possível que o RTB gere um prefixo para 160.0.0.0 sem gerar uma entrada
para 160.10.0.0, mesmo com a utilização do comandoY+++Y8
8. O RTB gera ambas as
redes, pois é o originiador de 160.10.0.0. Existem duas soluções para este problema.

A primeira solução é utilizar uma rota estática e redistribuir no BGP. O resultado é que o RTB anuncia o
agregado com uma origem incompleta (G).

Y
Y
Y Y

 Y Y Y Y
  Y Y
Y
YYYYYYYYYYYYYYY YY
Y Y  . +)Y
Y
3Y
Y%YY% *Y Y
 Y%Y6% 6Y
YYYYYYYYYYYYY
 YY +    Y   Y Y
Na segunda solução, além da rota estática, você adiciona uma entrada ao comando /0. Esta entrada
possui o mesmo efeito, exceto que a entrada define a origem da atualização para o IGP.

Y
Y
Y Y
-$Y +    Y $Y   Y
Y
YYYYYYYYYYYYYYY Y Y 
Y
% Y Y  . +)Y%Y

 YY
YYYYYYYYYYYYY

 Y Y Y Y
  Y Y
 YY +    Y   Y YY
9!
YY#&YY45YY

A instrução  é utilizada em agregação para reduzir o tamanho da informação de caminho. Com ,
o número de AS é listado apenas uma vez, independente de quantas vezes aparecer em caminhos diversos
que foram agregados. Você utiliza o comando +++Y em situações em que a agregação de
informações causa perda de informações relacionada ao atributo de caminho. Neste exemplo, o RTC é
atualizado sobre 160.20.0.0 do RTA e atualiza sobre 160.10.0.0 do RTB. Suponhamos que o RTC deseje
agregar a rede 160.0.0.0/8 e enviá-la ao RTD. O RTD não conhece a origem daquela rota. Se você adicionar
a instrução +++Y, forçará o RTC a gerar informações de caminho no formato de um conjunto >?.
Este conjunto inclui todas as informações de caminho, independente de que caminho veio primeiro.

Y
Y
Y Y
-$Y +    Y

 Y Y Y Y
Y
Y
Y
Y Y
-$Y +    Y

 Y Y Y Y
Caso 1:

O RTC não possui uma instrução . O RTC envia uma atualização 160.0.0.0/8 ao RTD com informação
de caminho (300), como se a rota tivesse originado no AS300.

Y
Y
Y Y

 YY Y Y

 YY Y Y

 Y%%%%Y Y% Y



Y +    Y   Y 22Y
Y
YYYYYYYYYYYYYYY Y Y%  Y- .YY$7Y "
Y
 . +2 Y&
Y38/Y Y$'Y
Y Y %
Y  Y3Y" (Y Y"
(Y Y Y
Y -
 Y
YY Y%

YY YY$'Y
Y Y 
Y
YYYY
YYYYYYYYYYYYY
YYYYYYYYYY
Caso 2:

Y
YYYY
Y Y
YYY
 YY Y Y
YYY
 YY Y Y
YYY
 Y%%%%Y Y% Y
YYY


Y +    Y   Y 22Y
YYY


Y +    Y   Y  Y
Y
YYYYYYYYYYYYYYY Y Y%  Y- .YY$7Y "
Y
 . +2 Y&
Y38/Y Y$'Y
Y %  Y  Y3Y
 % Y YY%Y9Y
:Y
YYYYYYYYYYYYY
YYYYYYYYYY
Os próximos dois assuntos, Confederação de BGP e Refletores de rota, são para provedores de serviços da
internet (ISPs) que desejam maior controle da explosão de peers iBGP dentro de seus ASs.

 $YYYY

A implementação da confederação de BGP reduz a malha do iBGP dentro de um AS. O truque é dividir um
AS em vários ASs e atribuir o grupo todo a uma única confederação. Cada AS sozinho possui iBGP
totalmente integrado e tem conexões a outros ASs dentro da confederação. Embora estes ASs possuam peers
eBGP em ASs dentro da confederação, os ASs trocam roteamento como se tivessem usado o iBGP. Desta
forma, a confederação preserva o próximo nó, a métrica e informações de preferência local. Para o mundo
externo, a confederação parece pertencer a um único AS.

Para configurar uma confederação de BGP, emita esse comando:

YYYYYYYYYYYY {Ô  {{ÔV  


Y
YYYYYYYYYY
O identificador da confederação é o número de AS do grupo da confederação.

A emissão deste comando faz correspondência entre diversos ASs dentro da confederação:

YYYYYYYYYYYY {Ô  {Ô   {


 

V  Y
YYYYYYYYYY
Abaixo encontra-se um exemplo de confederação:

Suponhamos que você possui um AS500 que consiste de nove interlocutores de BGP. Também existem
interlocutores que não são de BGP, mas você só está interessado em interlocutores de BGP que possuem
conexões eBGP a outros ASs. Se você deseja fazer uma malha de iBGP completa no AS500, precisa de
nove conexões de peer para cada roteador. Você precisa de oito peers de iBGP e um peer de eBGP para ASs
externos.

Se utilizar a confederação, você pode dividir o AS500 em diversos ASs: AS50, AS60, e AS70. Você fornece
ao AS um identificador de confederação 500. O mundo externo verá apenas um AS, o AS500. Para cada um,
o AS50, o AS60 e o AS70, defina uma malha completa de peers de iBGP e uma lista de peers de
confederação com o comando ,+!Y  $  Y!Y.

Aqui está um modelo de configuração dos roteadores RTC, RTD e RTA:

,"-YO RTA não tem conhecimento do AS50, do AS60, ou do AS70. O RTA tem conhecimento
somente do AS500.

Y
Y
Y Y

Y'Y'Y Y

Y'Y  Y+ Y Y

 Y *   Y Y Y7 YY-
" 8Y

 Y *   Y Y Y7 YY-
" 8Y

 Y    Y Y+ Y7 YY-Y
'Y Y+ 8Y

 Y   % Y Y Y7 YY-Y
'Y Y 8Y

 YY Y Y7c YYY
#Y" 8Y
Y
 Y
Y
Y+ Y

Y'Y'Y Y

Y'Y  Y Y Y

 Y   Y Y+ Y7 YY-
"+ 8Y

 Y *   Y Y 7 YY-Y
'Y Y 8Y

 Y   % Y Y Y7 YY-Y
'Y Y 8Y

 Y++++Y Y+ Y7c YYY
#Y"+ 8Y
Y
Y
YYYY
Y Y
YYY
 Y%Y Y Y7c YYY
'Y 8Y
&$
YYYY

Outra solução para a explosão de correspondência de iBGP em um AS são os Refletores de rota (RRs).
Como a seção iBGP demonstra, um interlocutor de BGP não anuncia uma rota que aprendeu de outro
interlocutor de iBGP a um terceiro interlocutor de iBGP. Você pode relaxar um pouco esta restrição e
fornecer controle adicional, que permite que um roteador anuncie ou reflita rotas aprendidas por iBGP a
outros interlocutores de iBGP. Esta reflexão de rota reduz o número de peers do iBGP dentro de um AS.

Em casos normais, mantenha uma malha completa de iBGP entre o RTA, o RTB e o RTC no AS100. Se
você utilizar o conceito RR, o RTC pode ser eleito como um RR. Desta forma, o RTC tem uma
correspondência parcial de iBGP com o RTA e o RTB. Correspondência entre o RTA e o RTB não é
necessária, pois o RTC é um RR para atualizações que vêm do RTA e do RTB.

YYYYYYYYYYYY{  ÔÔ  Ô Ô {Y


YYYYYYYYYY
O roteador com este comando é o RR e os vizinhos para os quais o comando aponta são os clientes daquele
RR. No exemplo, a configuração do RTC possui o comando  +*,Y$
 
 Yque aponta
para os endereços de IP do RTA e do RTB. A combinação do RR e dos clientes é um "cluster". Neste
exemplo, o RTA, o RTB e o RTC formam um cluster com um único RR no AS100.

Peers de iBGP do RR que não são clientes são "não clientes".

Um AS pode ter mais de um RR. Nesta situação, um RR trata outros RRs como qualquer interlocutor de
iBGP. Outros RRs podem pertencer ao mesmo cluster (grupo de clientes) ou a outros clusters. Em uma
configuração simples, é possível dividir o AS em diversos clusters. Você configura cada RR com outros
RRs como peers não clientes em uma topologia totalmente integrada. Clientes não devem corresponder-se
com interlocutores de iBGP fora do cluster de cliente.

Considere este diagrama. O RTA, o RTB e o RTC formam um único cluster. O RTC é o RR. Para o RTC,
RTA e RTB são clientes e qualquer outra coisa é um não cliente. Lembre-se que o comando  +*,Y
$
 
  aponta para clientes de um RR. O mesmo RTD é o RR para clientes RTE e RTF. O
RTG é um RR em um terceiro cluster.

,"-Y O RTD, o RTC e o RTG estão totalmente integrados, mas roteadores em um cluster não
estão. Quando um RR recebe uma rota, esta lista mostra as rotas do RR. No entanto, esta atividade depende
do tipo de peer:

1.YRotas de um peer não cliente ² Reflete para todos os clientes dentro de um cluster.
2.YRotas de um peer cliente ² Reflete para todos os peers não clientes além dos peers clientes.
3.YRotas de um peer eBGP ² Envia a atualização para todos os peers clientes e não clientes.

Aqui está a configuração de BGO relativa dos roteadores RTC, RTD e RTB:

Y
Y
Y
Y Y

 YY Y Y

 YY'Y

 Y    Y Y Y

 Y    Y'Y

 YY Y Y

 Y%%%%Y Y Y

 Y****Y Y Y
Y
Y
Y
Y
Y
Y Y

 YY Y Y

 Y    Y Y Y
Y
Y
 Y
Y
Y
Y Y

 Y++++Y Y Y

 Y++++Y'Y

 YY Y Y

 YY'Y

 YY Y Y

 YY Y Y
Pode haver um loop de informação de roteamento, pois há um reflexo das rotas aprendidas do iBGP. O
esquema do RR possui alguns métodos para evitar este loop:

AY  +   ² Este é um atributo opcional e intransitivo de BGP com o tamanho de 4 bytes. Um


RR cria este atributo. O atributo carrega a ID do roteador (RID) do originador da rota no AS local.
Se, por causa de configurações ruins, as informações de roteamento retornarem ao originador, as
informações são ignoradas.
AY

 ² A seção Diversos RRs em um cluster cobre a lista de clusters.

# "Y&&YYY
YY
Normalmente, um cluster de clientes possui um único RR. Neste caso, a ID do roteador do RR identifica o
cluster. Para aumentar a redundância e evitar pontos únicos de falhas, um cluster pode ter mais de um RR. É
preciso configurar todos os RRs no mesmo cluster com uma ID de cluster de 4 bytes para que o RR possa
reconhecer atualizações de RRs no mesmo cluster.

Uma lista de clusters é uma seqüência de IDs de cluster que a rota passou. Quando um RR reflete uma rota
dos clientes de RR para não clientes fora do cluster, ele anexa a ID de cluster local à lista de clusters. Se esta
atualização tiver uma lista de clusters vazia, o RR cria uma. Com este atributo, um RR pode identificar se as
informações de roteamento sofreram loopback para o mesmo cluster por causa de configurações ruins. Se a
ID de cluster local for encontrada na lista de clusters, o anúncio será igonorado.

No diagrama desta seção, o RTD, o RTE, o RTF e o RTH pertencem a um cluster. Tanto o RTD quanto o
RTH são RRs do mesmo cluster.

,"-YOcorre redundância porque o RTH possui correspondência totalmente integrada com todos os
RRs. Se o RTD ficar inativo, o RTH toma seu lugar.

Aqui está a configuração do RTH, do RTD, do RTF e do RTC:

AY
Y
Y
Y Y

 Y%%%%Y Y Y

 YY Y Y

 YY'Y

 Y++++Y Y Y

 Y++++Y'Y

 YY Y Y

 YY Y Y

 YY Y Y

Y Y Y
Y
Y
 Y
Y
Y
Y Y

 Y    Y Y Y

 YY Y Y

 YY'Y

 Y++++Y Y Y

 Y++++Y'Y

 YY Y Y

 YY Y Y

 Y    Y Y% Y

Y Y Y
Y
Y
CY
Y
Y
Y Y

 Y    Y Y Y

 Y%%%%Y Y Y

 Y    Y Y Y
Y
Y
Y
Y
Y
Y Y

 Y    Y Y Y

 Y    Y'Y

 YY Y Y

 YY'Y

 Y%%%%Y Y Y

 YY Y Y

 Y    Y Y Y

 Y****Y Y Y
,"-YVocê não precisa do comando ,+!Y
  para o RTC, pois só existe um RR naquele
cluster.

,"Y ! - Esta configuração não utiliza grupos de peer. Não utilize grupos de peer se os
clientes dentro de um cluster não possuírem peers de iBGP diretos entre si e os clientes trocarem
atualizações pelo RR. Se você configura grupos de peer, uma retirada potencial para a origem de uma rota
no RR transmite para todos os clientes no cluster. Essa transmissão pode causar problemas.

O subcomando do roteador ,+!Y


 
 Y$
   está habilitado por padrão no RR. Se você
desligar o reflexo cliente para cliente do BGP no RR e fazer correspondências de BGP redundantes entre os
clientes, pode utilizar grupos de peer com segurança.

 
 YYY  "   YY&&YY

Um AS pode ter interlocutores de BGP que não entendem o conceito de RRs. Este documento chama estes
roteadores de interlocutores de BGP convencionais. O esquema de RR permite que interlocutores de BGP
convencionais coexistam. Estes roteadores podem ser membros de um grupo de clientes ou de não clientes.
A existência destes roteadores permite migrações graduais e fáceis do modelo de iBGP atual para o modelo
de RR. Você pode começar a criar clusters se configurar um único roteador como RR e tornar outros RRs e
clientes de RR peers de iBGP normais. Depois, você pode criar mais clusters gradualmente.

Neste diagrama, o RTD, o RTE e o RTF têm o conceito de reflexo de rotas. O RTC, o RTA e o RTB são
roteadores "convencionais". Não é possível configurar estes roteadores como RRs. Você pode fazer uma
malha de iBGP normal entre ester roteadores e o RTD. Mais tarde, quando estiver pronto para melhorar,
você pode tornar o RTC um RR com os clientes RTA e RTB. Clientes não precisam entender o esquema de
reflexo de rotas; somente os RRs precisam de atualização.

Aqui está a configuração do RTD e do RTC:

 Y
Y
Y
Y Y

 Y++++Y Y Y

 Y++++Y'Y

 YY Y Y

 YY'Y

 YY Y Y

 YY Y Y

 Y    Y Y Y

 Y    Y Y Y
Y
Y
Y
Y
Y
Y Y

 Y%%%%Y Y Y

 YY Y Y

 Y    Y Y Y

 Y % % % %Y Y% Y
Quando estiver pronto para melhorar o RTC e torná-lo um RR, remova a malha completa do uBGP e faça
com que o RTA e o RTB tornem-se clientes do RTC.

" Y
!YY $%YY Y Y

Por enquanto, este documento mencionou dois atrubutos que podem ser usados para evitar um loop de
informações potencial:  +   e

.

Outro modo de controlar loops é colocando mais restrições na cláusula de $  de mapas de rotas
externas. A cláusula de $  para mapas de rotas externas não afeta rotas que refletem para peers de
iBGP.

Você também pode colocar mais restrições em 9*!


$, que é uma opção de configuração por vizinho.
Ao utilizar 9*!
$ em RRs, a cláusula afeta somente o próximo nó de rotas aprendidas do eBGP, pois
o próximo nó de rotas refletidas não deve ser alterado.

&  YY  YYYY

A versão 11.0 do Cisco IOS Software introduziu o retardamento de rota. Retardamento de rota é um
mecanismo para minimizar a instabilidade causada por sincronismo de rota. Retardamento de rota também
reduz a oscilação sobre a rede. Você define os critérios para identificar rotas com mal comportamento. Uma
rota que sincroniza recebe uma pena de 1000 para cada sincronismo. Assim que a pena cumulativa chega a
um "limite de supressão" predefinido, ocorre supressão do anúncio de rota. A pena decai exponencialmente
baseada em um "período de meia-vida" pré-configurado. Uma vez que a pena diminui até um "limite de
reutilização" predefinido, ocorre a insupressão do anúncio de rota.

O retardamento de rota não se aplica a rotas externas a um AS e aprendidas por iBGP. Dessa forma, o
retardamento de rota evita uma pena maior para os peers de iBGP de rotas externas ao AS.

A pena decai a uma granularidade de 5 segundos. A insupressão das rotas ocorre a uma granularidade de 10
segundos. O roteador mantém as informações de retardo até que a pena torne-se menos que a metade do
"limite de reutilização". Neste ponto, o roteador limpa as informações.

Inicialmente, o retardamento está desativado por padrão. Se houver necessidade, este recurso pode receber
habilitação por padrão no futuro. Estes comandos controlam o retardamento de rota:

AY ,+!Y! + ² Ativa o retardamento.


AY Y,+!Y! + ² Desativa o retardamento.
AY ,+!Y! +YV   Y² Altera o período de meia-vida.

Um comando que define todos os parâmetros ao mesmo tempo é:

AY ,+!Y! +YV   Y


Y
 

YV
 

Y

Esta lista detalha a sintaxe:

AY V   Y² O alcance é de 1±45 minutos e o padrão atual é de 15 minutos.


AY 
 ëVY² O alcance é de 1±20,000 e o padrão é de 750.
AY
 

ëVY² O alcance é de 1±20,000 e o padrão é de 2000.


AY V
 

Y² Esta é a duração máxima da supressão de uma rota. O alcance é de 1±255


minutos e o padrão é de 4 vezes o período de meia-vida.

Y
 Y Y
Y
'Y" Y
Y Y Y   YY
Y
'Y" Y
Y Y Y  * +YY
Y
Y
Y Y
Y
Y 
Y
Y-$Y    Y
Y
 Y  * Y Y Y
Y
Y
 Y
 Y  Y
Y
'Y) $ Y
 Y Y  *  %Y Y
Y
'Y" 6 Y
Y Y Y  * YY
Y
Y
Y Y
Y-$Y  *  Y
Y
 Y  * +Y Y Y
A configuração de RTB é para retardamento de rede com parâmetros padrão. Supondo que o link do eBGP
ao RTD seja estável, a tabela de BGP do RTB é semelhante a:

Y Y
 Y Yë Y Y%!YYY Y Y   Y
" Y (Y Y
  !YY !YY 2!Y;Yë!YDY  !YYY
Y0
Y
 (YYY !YYYc !YGYY Y
Y
YYY9-$YYYYYYYYYY9#YA YYYYYYYYYY,Y) 'YE
Y
Y
;DY  *  YYYYY  * YYYYYYYYYYY YYYYYYYYYYYYY
 YY
;DY    YYYYY    YYYYYYYYYYYYYYYY YYYYYYYYY+*
Y
Para simular um sincronismo de rota, emita o comando
Y !Y,+!Y132E323B no RTD. A tabela de
BGP do RTB é semelhante a:

Y Y
 Y Yë Y Y%!YYY Y Y   Y
" Y (Y Y
  !YY !YY 2!Y;Yë!YDY  !YYY
Y0
Y
 (YYY !YYYc !YGYY Y
Y
YYY9-$YYYYYYYYYY9#YA YYYYYYYYYY,Y) 'YE

Y
YY  *  YYYYY  * YYYYYYYYYYY YYYYYYYYYYYYY
 YY
;DY    YYYYY    YYYYYYYYYYYYYYYY YYYYYYYYY+*
Y
A entrada do BGP para 192.208.10.0 está em um estado  F . Esta localização significa que você
não tem um caminho melhor para a rota, mas ainda existe informação sobre a sincronia da rota.

Y '(& &!) '! !Y


 Y
Y Y2Y'Y  *  Y !Y
ë YY
 (Y7 Yë !YY  Y 8Y
 Y7 2Y28Y
YYYY  * Y'Y  * Y7  *  %8Y
0
Y !YY !Y#Y
 '(Y 2Y !Y' Y Y YY ( ( Y
A rota recebeu uma pena por sincronismo, mas a pena ainda está abaixo do "limite de supressão". O padrão
é 2000. A supressão de rota ainda não ocorreu. Se ocorrer o sincronismo de rota mais algumas vezes, você
verá:

Y Y
 Y Yë Y Y!YYY Y Y   Y
" Y (Y
Y   !YY !YY 2!Y;Yë!YDY  !YYY
Y0
Y (Y
YY !YYYc !YGYY Y
Y
YYY9-$YYYYYYYYYY9#YA YYYYYYYYYY,Y) 'YE

Y
;Y  *  YYYYY  * YYYYYYYYYYY YYYYYYYYYYYYY
 YY
;DY    YYYYY    YYYYYYYYYYYYYYY YYYYYYY+*YYY
Y
Y '(& &!) '! !Y
 Y
Y Y2Y'Y  *  Y !Y
ë YY
 (Y7 Yë !YY  Y 8Y
 !Y7   YYY 
8Y
 * Y'Y  * Y7  *  %8Y
YYYYYY0
Y !YY !Yë!Y#Y
 '(Y 2Y+ !Y' YY YY ( ( *Y!Y 
Y (( Y
A rota foi retardada ou suprimida. A rota é reutilizada quando a pena alcança "valor de reutilização". Neste
caso, o valor de reutilização é o padrão, 750. As informações de retardamento são limpas quando a pena
torna-se menor do que metade do limite de reutilização. Neste caso, a limpeza ocorre quando a pena torna-se
375 (750/2=375). Estes comandos exibem e limpam informações de estatística de sincronismo:

AY */Y !Y,+!Y$
!   ² Exibe estatísticas de sincronismo para todos os caminhos.
AY */Y !Y,+!Y$
!  Y+9!YV  

{Y² Exibe estatísticas de sincronismo para


todos os caminhos que correspondem a expressões regulares.
AY */Y !Y,+!Y$
!  Y$

Y
Y² Exibe estatísticas de sincronismo para todos os
caminhos que passem pelo filtro.
AY */Y !Y,+!Y$
!  Ya      Y² Exibe estatísticas de sincronismo para uma única
entrada.
AY */Y !Y,+!Y$
!  Ya      Y² Exibe estatísticas de sincronismo para entradas
mais específicas.
AY */Y !Y,+!Y  +*,YF!  GY?YF$
!  GY² Exibe estatísticas de sincronismo
para todos os caminhos de um vizinho.
AY
Y !Y,+!Y$
!  Y² Limpa estatísticas de sincronismo para todas as rotas.
AY
Y !Y,+!Y$
!  Y+9!YV  

{Y² Limpa estatísticas de sincronismo para


todos os caminhos que correspondem a expressões regulares.
AY
Y !Y,+!Y$
!  Y$

Y
Y² Limpa estatísticas de sincronismo para todos os
caminhos que passem pelo filtro.
AY
Y !Y,+!Y$
!  Ya      Y² Limpa estatísticas de sincronismo para uma única
entrada.
AY
Y !Y,+!Ya   Y$
!   ² Limpa estatísticas de sincronismo para todos os caminhos de
um vizinho.

YYY
  YY  *Y Y

Agora que você está familiarizado com atributos e terminologia do BGP, consulte Algoritmo de seleção de
melhor caminho do BGP.

YY YYYYY
9!
YY!HY!7 YY

Esta seção contém um exemplo de projeto que mostra as tabelas de configuração e de roteamento conforme
as tabelas realmente aparecem em roteadores da Cisco.

Esta seção mostra como construir esta configuração passo a passo e o que pode dar errado no caminho.
Quando você possuir um AS que conecta-se a dois ISPs por eBGP, sempre execute o iBGP no seuu AS para
ter maior controle sobre suas rotas. Neste exemplo, o iBGP executa dentro do AS100 entre o RTA e o RTB,
e o OSPF executa como um IGP. Suponhamos que você se conecte a dois ISPs, o AS200 e o AS300. Esta é
a primeira execução das configurações para todos os roteadores:

,"-YEssas não são as configurações finais.

Y
 Y Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y   % Y Y
Y
'Yc Y
 Y Y   % Y Y
Y
'Y" Y
Y Y Y * + YY
Y
Y 'Y Y
Y-$Y    Y  YY Y
Y
Y
Y Y
Y-$Y    Y
Y-$Y   % Y
Y
 Y * +Y Y Y
Y
 Y   Y Y Y
Y
 Y   Y  Y) $ Y
Y
CY
 Y CY
Y
 Y  3Y
Y
'Yc Y
Y Y Y   %Y Y
Y
'Y" Y
Y Y Y    YY
Y
Y 'Y Y
Y-$Y    Y  YY Y
Y
Y
 Y Y
Y
 Y  3Y
Y
'Y" Y
Y Y Y   YY
Y
'Y" Y
Y Y Y  * +YY
Y
Y 'Y Y
Y-$Y    Y  YY Y
Y
Y
Y Y
-$Y    Y
Y
 Y  * Y Y Y
Y
 Y   % Y Y Y
Y
Y
 Y Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y * +  Y Y
Y
'Y"6 Y
Y Y Y * +YY
GY
'Y"6 Y
Y Y Y * +YY
Y
Y
Y Y
Y-$Y *   Y
Y
 Y * + Y Y Y
Y
 Y * ++Y Y% Y
Y
 Y
 Y  Y
Y
 Y  3Y
Y
'Y) $ Y
 Y Y  *  %Y Y
Y
'Y" 6 Y
Y Y Y  * YY
GY
'Y" 6 Y
Y Y Y  * YY
Y
Y
Y Y
Y-$Y  *  Y
Y
 Y  *  Y Y Y
Y
 Y  * +Y Y Y
Y
cY
 Y cY
Y
 Y  3Y
Y
'Y) $ Y
 Y Y    Y Y
Y
'Y" Y
Y Y Y   YY
Y
'Y" Y
Y Y Y * ++YY
Y$Y Y
Y
Y
Y% Y
Y-$Y    Y
Y
 Y * +Y Y Y
Y
 Y    Y Y Y
Y
Y
 Y Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y    %Y Y
Y
'Y" Y
Y Y Y  *  YY
Y
'Y" Y
Y Y Y    YY
Y
Y
Y Y
Y-$Y    Y
Y
 Y  * Y Y Y
Y
 Y   Y Y% Y
Sempre utilize o comandoY /0 ou redistribua entradas estáticas no BGP para anunciar redes. Este
método é melhor do que redistribuição de IGP no BGP. O exemplo utiliza o comando /0para
injetarredes no BGP.

Aqui, você inicia com a interface s1 no fechamento do RTB, como se o vínculo entre o RTB e o RTD não
existisse. Esta é a tabela de BGP do RTB:

Y Y
 Yë Y Y%!YYY Y Y   Y" Y
 (Y Y   !YY !YY 2!Y;Yë!YDY  !
YYY
0
Y (YYY !YYYc !YGYY Y
YYYYY9-$YYYYYYYYYY9#YA YYYYYYYYYY,Y) 'Y
E
Y Y
; *   YYYYYY * +YYYYYYYYYYY YYYY YYYYYY Y
 YY
;  *  YYYYY * +YYYYYYYYYYYYYYYY YYYYYY Y
 Y% Y Y
 YY
;    YYYYY * +YYYYYYYYYYYYYYYY YYYYYY Y
 Y% Y YY
;    YYYYY * +YYYYYYYYYYYYYYYY YYYYYY Y
 Y% YY
;D    YYYY   % YYYYYYYYYY YYYY YYYYYY Y
Y
;D   % YYYY   % YYYYYYYYYY YYYY YYYYYY Y
Y
;D    YYYYY    YYYYYYYYYYYYYYYY YYYYYYYYY+*Y
Y
Nesta tabela aparecem estas notas:

AY Um  no começo ² Indica que a entrada foi aprendida por um peer do iBGP.


AY Um  no fim ² Indica que a origem da informação de caminho é IGP.
AY 'H de caminho ² Esta informação é intuitiva. Por exemplo, a rede 128.213.0.0 foi
aprendida pelo caminho 200 com um próximo nó de 128.213.63.2.

,"-YQualquer entrada gerada localmente, como 203.250.15.0, tem um próximo nó


0.0.0.0.

AY Um D ² Indica que o BGP escolheu a melhor rota. O BGP utiliza os passos de decisão que o
documento Algoritmo de seleção de melhor caminho do BGP descreve. O BGP escolhe um melhor
caminho para alcançar um destino, instala o caminho na tabela de IP Routing e anuncia o caminho
para outros peers de BGP.

,"-YObserve o atributo F#YF . O RTB conhece o 128.213.0.0 pelo próximo nó


128.213.63.2, que é o próximo nó do eBGP carregado no iBGP.

Observe a tabela de IP routing:

Y Ô Y


 (YYY!Y"YY !YYY !Y YY  !Y,YY
 !YYY Y
YYYYYYY YYc !YcYYc Y#!Y0YY0" C!YYY0" CY
YY
YYYYYYYc YY0" CY#Y2 Y !YcYY0" CY#Y2 Y
!YcYYc Y
YYYYYYYYY""!Y) YY""Yë !Y)YY""Yë!Y
;YYY
'Y
Y
-2Y'Y Y Y YY Y
Y
YYYYY    YY Y  !Y Y   Y
0YYYYYYY   % Y@ 6<YëY    !Y ( (%!
" Y
YYYYY    YY Y  !Y Y   Y
YYYYYYY    Y Y2Y!Y" Y
0YYYY   % Y@ 6%<YëY    !Y ( (%+!Y
" Y
Aparentemente, nenhuma das entradas de BGP alcançou a tabela de roteamento. Existem dois problemas
aqui.

O primeiro problema é que é impossível alcançar o próximo nó para estas entradas, 128.213.63.2. Não há
como alcançar aquele próximo nó por este IGP, que é OSPF. O RTB não aprendeu sobre 128.213.63.0 pelo
OSPF. É possível executar o OSPF na interface s0 do RTA e torná-lo passivo; dessa forma, o RTB sabe
como alcançar o próximo nó 128.213.63.2. Esta configuração de RTA aparece aqui:

Y
 Y Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y   % Y Y
Y
'Yc Y
 Y Y   % Y Y
Y
'Y" Y
Y Y Y * + YY
Y
Y 'Y Y
Y  ë'Y" Y
Y-$Y    Y  YY Y
Y-$Y *   Y  YY Y
Y
Y
Y Y
Y-$Y    Y $Y  Y
Y
 Y * +Y Y Y
Y
 Y   Y Y Y
Y
 Y   Y  Y) $ Y
,"-YVocê pode emitir o comando ,+!Y 9*!
$ entre o RTA e o RTB para alterar o próximo
nó.

A nova tabela de BGP no RTB é semelhante a:

Y Y
 Y Yë Y Y !YYY Y Y   Y
" Y (Y Y   !YY !YY 2!Y;Yë!Y
DY  !Y
YYY0
Y (YYY !YYYc !YGYY
 Y
Y
YYY9-$YYYYYYYYYY9#YA YYYYYYYYYY,Y) 'YE

Y
;D *   YYYYYY * +YYYYYYYYYYY YYYY YYYYYY
 YY
;D  *  YYYYY * +YYYYYYYYYYYYYYYY YYYYYY
 Y% Y Y
 YY
;D    YYYYY * +YYYYYYYYYYYYYYYY YYYYYY
 Y% Y YY
;D    YYYYY * +YYYYYYYYYYYYYYYY YYYYYY
 Y% YY
;D    YYYYY   % YYYYYYYYYY YYYY YYYYYY
Y
;D   % YYYYY   % YYYYYYYYYY YYYY YYYYYY
Y
;DY    YYYYY    YYYYYYYYYYYYYYYY YYYYYYYYY+*Y
Y
,"-YTodas as entradas têm D, que significa que o BGP pode alcançar o próximo nó.

Observe a tabela de roteamento:

Y Ô Y


 (YYY!Y"YY !YYY !Y YY  !Y,YY
 !YYY Y
YYYYYYY YYc !YcYYc Y#!Y0YY0" C!YYY0" CY
YY
YYYYYYYc YY0" CY#Y2 Y !YcYY0" CY#Y2 Y
!YcYYc Y
YYYYYYYYY""!Y) YY""Yë !Y)YY""Yë!Y
;YY
Y'Y
Y
-2Y'Y Y Y YY Y
Y
YYYYY    YY Y  !Y Y   Y
0YYYYYYY   % Y@ 6<YëY    !Y ( %(%+!
" Y
YYYYY    YY Y  !Y Y   Y
YYYYYYY    Y Y2Y!Y" Y
0YYYY   % Y@ 6%<YëY    !Y ( %(%+!Y
" Y
YYYYY *   YY Y  !Y Y   Y
0YYYYYYY * + Y@ 6 *<YëY    !Y ( %(%!
" Y
O segundo problema é que você ainda não vê as entradas de BGP na tabela de roteamento. A única
diferença é que 128.213.63.0 agora pode ser alcançado por OSPF. Este problema é uma questão de
sincronização. O BGP não coloca estas entradas na tabelas de roteamento e não envia as entradas em
atualizações de BGP por causa de uma falta de sincronização com o IGP.

,"-YO RTF não tem noção de redes 192.208.10.0 e 195.211.10.0 porque você ainda não
redistribuiu BGP em OSPF.

Neste cenário, se você desativar a sincronização, as entradas aparecerão na tabela de roteamento. Mas a
conectividade ainda estará quebrada.

Isso é o que acontecerá se você desativar a sincronização no RTB:

Y Ô Y


 (YYY!Y"YY !YYY !Y YY  !Y,YY
 !YYY Y
YYYYYYY YYc !YcYYc Y#!Y0YY0" C!YYY0" CY
YY
YYYYYYYc YY0" CY#Y2 Y !YcYY0" CY#Y2 Y
!YcYYc Y
YYYYYYYYY""!Y) YY""Yë !Y)YY""Yë!Y
;YY
Y'Y
Y
-2Y'Y Y Y YY Y
Y
YYYY    Y@ 6 <YëY * +!Y ( ( Y
YYYY    Y@ 6 <YëY * +!Y ( ( Y
YYYY  *  Y@ 6 <YëY * +!Y ( ( Y
YYYYY    Y Yë 2Y  !YY   !YY
 $ Y
0YYYYYYY   % YY
YYYYYYYYYYY@ 6<YëY    !Y ( (!Y" Y
YYYYYYY    Y Y@ 6 <YëY
   % !Y ( ( *Y
YYYYY    YY Y  !Y Y   Y
YYYYYYY    Y Y2Y!Y" Y
0YYYY   % Y@ 6%<YëY    !Y ( (!Y
" Y
YYYYY *   Y Yë 2Y  !YY   !YY $ Y
YYYYYYY *   Y  Y@ 6 <YëY * +!Y
( ( *Y
0YYYYYYY * + YY
YYYYYYYYYYY@ 6 *<YëY    !Y ( (!Y" Y
A tabela de roteamento parece normal, mas não há como alcançar aquelas redes. O RTF no meio não sabe
como alcançar as redes:

CY Ô Y


 (YYY!Y"YY !YYY !Y YY  !Y,YY
 !YYY Y
YYYYYYY YYc !YcYYc Y#!Y0YY0" C!YYY0" CY
YY
YYYYYYYc YY0" CY#Y2 Y !YcYY0" CY#Y2 Y
!YcYYc Y
YYYYYYYYY""!Y) YY""Yë !Y)YY""Yë!Y
;YY
Y'Y
Y
-2Y'Y Y Y YY Y
Y
YYYYY    YY Y  !Y Y   Y
0YYYYYYY   % Y@ 6 <YëY   % !Y ( %( !
c Y
YYYYY    YY Y  !Y Y   Y
YYYYYYY    Y Y2Y!Y" Y
YYYY   % Y Y2Y!Yc Y
YYYYY *   YY Y  !Y Y   Y
0YYYYYYY * + Y@ 6%<YëY   % !Y ( %( !Y
c Y
Ao desativar a sincronização nesta situação, o problema ainda existe. Mas você precisará da sincronização
mais tarde para outras questões. Redistribua o BGP em OSPF no RTA, com uma métrica de 2000:

Y
 Y Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y   % Y Y
Y
'Yc Y
 Y Y   % Y Y
Y
'Y" Y
Y Y Y * + YY
Y
Y 'Y Y
Y  Y
Y YY Y   Y
Y  ë'Y" Y
Y-$Y    Y  YY Y
Y-$Y *   Y  YY Y
Y
Y
Y Y
Y-$Y    Y $Y  Y
Y
 Y * +Y Y Y
Y
 Y   Y Y Y
Y
 Y   Y  Y) $ Y
A tabela de roteamento é semelhante a:

Y Ô Y


 (YYY!Y"YY !YYY !Y YY  !Y,YY
 !YYY Y
YYYYYYY YYc !YcYYc Y#!Y0YY0" C!YYY0" CY
YY
YYYYYYYc YY0" CY#Y2 Y !YcYY0" CY#Y2 Y
!YcYYc Y
YYYYYYYYY""!Y) YY""Yë !Y)YY""Yë!Y
;YY
Y'Y
Y
-2Y'Y Y Y YY Y
Y
0YcY    Y@ 6 <YëY    !Y ( ( %!Y
" Y
0YcY    Y@ 6 <YëY    !Y ( ( %!Y
" Y
0YcY  *  Y@ 6 <YëY    !Y ( ( %!Y
" Y
YYYYY    Y Yë 2Y  !YY   !YY
 $ Y
0YYYYYYY   % YY
YYYYYYYYYYY@ 6<YëY    !Y ( ( !Y" Y
0YcYYYY    Y Y
YYYYYYYYYYY@ 6 <YëY    !Y ( ( !Y" Y
YYYYY    YY Y  !YY   Y
YYYYYYY   *Y Y2Y!Y) $ Y
YYYYYYY    Y Y2Y!Y" Y
0YYYY   % Y@ 6%<YëY    !Y ( ( !Y
" Y
YYYYY *   Y Yë 2Y  !YY   !YY $ Y
0YcYYYY *   Y  Y@ 6 <YëY
    !Y
( ( !" Y
0YYYYYYY * + YY
YYYYYYYYYYY@ 6 *<YëY    !Y ( ( +!Y" Y
As entradas de BGP disapareceram porque o OSPF tem uma distância melhor que o iBGP. A distância do
OSPF é 110, enquanto a do iBGP é 200.

Desative a sincronização no RTA para que ele possa anunciar 203.250.25.0. Esta ação é necessária, pois o
RTA não faz sincronização com o OSPF por causa da diferença em máscaras. Mantenha a sincronização
desativada no RTB para que ele possa anunciar 203.250.13.0. Esta ação é necessária no RTB pela mesma
razão.

Agora, ative a interface s1 do RTB para ver como são as rotas. Além disso, habilite o OSPF em serial 1 do
RTB para torná-lo passivo. Esta etapa permite que o RTA saiba sobre o próximo nó 192.208.10.5 pelo IGP.
Se você não concluir esta etapa, ocorrerão loops de roteamento, pois, para alcançar o próximo nó
192.208.10.5, você precisa ir para o outro lado pelo eBGP. Estas são as novas configurações do RTA e do
RTB:

Y
 Y Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y   % Y Y
Y
'Yc Y
 Y Y   % Y Y
Y
'Y" Y
Y Y Y * + YY
Y
Y 'Y Y
Y  Y
Y YY Y   Y
Y  ë'Y" Y
Y-$Y    Y  YY Y
Y-$Y *   Y  YY Y
Y
Y
Y Y
YY 23Y
Y-$Y    Y
Y-$Y   % Y
Y
 Y * +Y Y Y
Y
 Y   Y Y Y
Y
 Y   Y  Y) $ Y
Y
Y
 Y Y
Y
 Y  3Y
Y
'Y" Y
Y Y Y   YY
Y
'Y" Y
Y Y Y  * +YY
Y
Y 'Y Y
Y  Y
Y YY Y   Y
Y  ë'Y" Y
Y-$Y    Y  YY Y
Y-$Y  *  Y  YY Y
Y
Y
Y Y
YY 23Y
Y-$Y    Y
Y
 Y  * Y Y Y
Y
 Y   % Y Y Y
As tabelas de BGP do RTB são semelhantes a:

Y Y
 Y Yë Y Y !YYY Y Y   % Y
" Y (Y Y   !YY !YY 2!Y;Yë!Y
DY  !Y
YY0
Y (YYY !YYYc !YGYY Y
Y
YYY9-$YYYYYYYYYY9#YA YYYYYYYYYY,Y) 'YE

Y
;DY *   YYYYYY * +YYYYYYYYYYY YYYYYYYYYYYYY
 YY
;D  *  YYYYY  * YYYYYYYYYYY YYYY YYYYYY
 YY
;D    YYYYY  * YYYYYYYYYYYYYYYY YYYYYY
 Y YY
;YYYYYYYYYYYYYYYYYYY * +YYYYYYYYYYYYYYYYYYYYYYYYY
 Y% Y YY
;DY    YYYYY * +YYYYYYYYYYYYYYYYYYYYYYYYY
 Y% YY
;DY    YYYYY    YYYYYYYYYYYYYYYY YYYYYYYYY+*
Y
;DY   % YYYYY    YYYYYYYYYYYYYYYY YYYYYYYYY+*Y
Y
;D    YYYYY   YYYYYYYYYYY YYYY YYYYYY
Y
Y
Y Y
 Y Yë Y Y !YYY Y Y    Y
" Y (Y Y   !YY !YY 2!Y;Yë!Y
DY  !Y
YY0
Y (YYY !YYYc !YGYY Y
Y
YYY9-$YYYYYYYYYY9#YA YYYYYYYYYY,Y) 'YE

Y
;D *   YYYYYY * +YYYYYYYYYYY YYYY YYYYYY
 YY
;YYYYYYYYYYYYYYYYYYY  * YYYYYYYYYYYYYYYYYYYYYYYYY
 Y Y% Y
 YY
;DY  *  YYYYY  * YYYYYYYYYYY YYYYYYYYYYYYY
 YY
;DY    YYYYY  * YYYYYYYYYYYYYYYYYYYYYYYYY
 Y YY
;D    YYYYY * +YYYYYYYYYYYYYYYY YYYYYY
 Y% YY
;YYYYYYYYYYYYYYYYYYY  * YYYYYYYYYYYYYYYYYYYYYYYYY
 Y Y% YY
;D    YYYYY   % YYYYYYYYYY YYYY YYYYYY
Y
;D   % YYYYY   % YYYYYYYYYY YYYY YYYYYY
Y
;DY    YYYYY    YYYYYYYYYYYYYYYY YYYYYYYYY+*
Y
Há diversas formas de projetar sua rede para falar com dois ISPs diferentes, o AS200 e o AS300. Uma delas
é ter um ISP primário e um ISP de backup. Você aprende rotas parciais de um dos ISPs e rotas padrão de
ambos os ISPs. Neste exemplo, você recebe rotas parciais do AS200 e apenas rotas locais do AS300. Ambos
o RTA e o RTB geram rotas parciais para o OSPF, com o RTB como preferência por causa da métrica
menor. Desta forma, você pode balancear tráfigo externo entre os dois ISPs.

Assimetria potencial pode ocorrer se o tráfego que sai do RTA voltar pelo RTB. Esta situação pode ocorrer
se você utilizar o mesmo conjunto de endereços de IP, a mesma rede principal, ao falar com dois ISPs. Por
causa da agregação, todo o seu AS pode parecer uma entidade inteira para o mundo externo. Pontos de
entrada para a sua rede podem ocorrer pelo RTA ou pelo RTB. Você pode descobrir que todo tráfego interno
do seu AS chega por um único ponto, embora você tenha diversos pontos para a internet. No exemplo, você
possui duas redes principais diferentes ao falar com os doisz ISPs.

Outra razão potencial para a assimetria é o diferente tamanho de caminho anunciado a chegar no seu AS.
Talvez um provedor de serviços esteja mais perto de certo destino do que outro. No exemplo, tráfego do
AS400 que tem sua rede como destino sempre vem pelo RTA por causa do caminho mais curto. Você pode
tentar afetar esta decisão. Você pode utilizar o comando Y!*Y!!  para anexar números de
caminho às suas atualizações e fazer a distância do caminho parecer mais comprida. Mas, com atributos
como preferência local, métrica ou ponderância, o AS400 pode ter definido o ponto de saída como o AS200.
Nesse caso, não há nada que você possa fazer.

Esta configuração é a configuração final para todos os roteadores:

Y
 Y Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y   % Y Y
Y
'Yc Y
Y Y Y   % Y Y
Y
'Y" Y
Y Y Y * + YY
Y
Y 'Y Y
Y  Y
Y YY Y   Y
Y  ë'Y" Y
Y-$Y    Y  YY Y
Y-$Y *   Y  YY Y
Y''Y
YY Y
Y
Y
Y Y
YY 23Y
-$Y    Y
Y-$Y   % Y
Y
 Y * +Y Y Y
Y
 Y * +Y Y  'YY
Y
 Y   Y Y Y
Y
 Y   Y  Y) $ Y
Y
 Y  Y
 Y'-$Y    Y
Y
 Y  'Y Y Y
Y Y 'Y Y
No RTA, a preferência local para rotas que vêm do AS200 está configurada para 200. Além disso, a rede
200.200.0.0 é a escolha para padrão de candidato. O comando !Y$
 /0 permite escolher o
padrão.

Também neste exemplo, a utilização do comando $


 $  Y +  com o OSPF injeta a rota
padrão dentro do domínio de OSPF. Este exemplo também utiliza este comando com o Protocolo sistema
intermediário a sistema intermediário (IS-IS Protocol) e com o BGP. Para o RIP, há uma redistribuição
automática no RIP de 0.0.0.0, sem configuração adicional. Para o IGRP e o EIGRP, a injeção da informação
padrão no domínio de IGP ocorre após redistribuição do BGP no IGRP e no EIGRP. Além disso, com o
IGRP e o EIGRP, você pode redistribuir uma rota estática para 0.0.0.0 no domínio de IGP.

CY
 Y CY
Y
 Y  3Y
Y
'Yc Y
Y Y Y   %Y Y
Y
'Y" Y
Y Y Y    YY
Y
Y 'Y Y
Y-$Y    Y  YY Y
Y
 Y  Y
Y
Y
 Y Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y    YY
Y
'Y" Y
Y Y Y   YY
GY
'Y" Y
Y Y Y  * +YY
Y
Y 'Y Y
Y  Y
Y YY Y   Y
Y  ë'Y" Y
Y-$Y    Y  YY Y
Y-$Y  * +Y    YY Y
Y''Y
YY Y
GY
Y
Y Y
YY 23Y
Y-$Y    Y
Y
 Y  * Y Y Y
Y
 Y  * Y Y2YY
Y
 Y   % Y Y Y
GY
 Y  Y
 Y'-$Y  *  Y
 Y  Y  Y Y Y4 5Y
Y
 Y2Y Y Y
YY  Y Y
Y 'Y Y
Para o RTB, a preferência local para atualizações que vem do AS300 está configurada para 300. Este valor é
mais alto que o valor de preferência local de atualizações do iBGP que vêm do RTA. Deste modo, o AS100
escolhe o RTB para rotas locais do AS300. Quaisquer outras rotas no, se existirem outras rotas, transmitem
internamente com uma preferência local de 100. Este valor é menos que a preferência local de 200, que vem
do RTA. Portanto o RTA é a preferência.

,"-YVocê anuncia apenas as rotas locais do AS300. Qualquer informação de caminho que não
corresponder a 4 5 é descartada. Se desejar anunciar as rotas locais e as rotas vizinhas, que são clientes
do ISP, utilize 4 D@ <;.

Aqui está a saída de expressões regulares que indica as rotas locais do AS300:

Y Ô*%!!+Y
 Y Yë Y Y %!YYY Y Y    Y
" Y (Y Y   !YY !YY 2!Y;Yë!Y
DY  !YYY
Y
0
Y (YYY !YYYc !YGYY Y
Y
YYY9-$YYYYYYYYYY9#YA YYYYYYYYYY,Y) 'YE

Y
;DY  *  YYYYY  * YYYYYYYYYYY YYYY YYYYYY
 Y
Y
Y
 Y Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y * +  Y Y
Y
'Y"6 Y
Y Y Y * +YY
GY
'Y"6 Y
Y Y Y * +YY
Y
Y
Y Y
Y-$Y *   Y
Y
 Y * + Y Y Y
Y
 Y * + Y   Y YY
Y
 Y * ++Y Y% Y
Y
 Y  Y
  Y Y2YYY    Y  Y
  Y Y Y2Y
No RTC, você agrega 128.213.0.0/16 e indica as rotas específicas para injeção no AS100. Se o ISP recusar-
se a realizar esta tarefa, você deve filtrar a extremidade de entrada do AS100.

 Y
 Y  Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y  *  %Y Y
GY
'Y" 6 Y
Y Y Y  * YY
GY
'Y" 6 Y
Y Y Y  * YY
Y
Y
Y Y
Y-$Y  *  Y
Y
 Y  *  Y Y Y
Y
 Y  * +Y Y Y
Y
Y
 Y Y
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y    %Y Y
Y
'Y" Y
Y Y Y  *  YY
Y
'Y" Y
Y Y Y    YY
Y
Y
Y Y
Y-$Y    Y
Y


 Y    Y  Y 22Y
Y
 Y  * Y Y Y
Y
 Y  * Y 2Y
Y
 Y  * Y Y 2YY
Y
 Y   Y Y% Y
GY
 Y  Y
  Y Y Y    Y  Y
  YY Y2Y
 Y 2Y Y Y
YY Y YY
GY
 Y 2Y Y Y
YY Y Y Y
Y Y2Y# Y
Uma demonstração da utilização de filtragem de comunidade está no RTG. Você adiciona uma comunidade
9! a atualizações de 195.211.0.0 para o RTD. Desta forma, o RTD não exportará a rota para o RTB.
No entanto, neste caso, o RTB não aceitará estas rotas de qualquer forma.

cY
 Y cY
Y
 Y  3Y
Y
'Y) $ Y
Y Y Y    Y Y
Y
'Y" Y
Y Y Y   YY
Y
'Y" Y
Y Y Y * ++YY
Y
Y
Y% Y
Y-$Y    Y
Y


 Y    Y  Y 22Y
Y
 Y * +Y Y Y
Y
 Y    Y Y Y
Y
 Y  Y
O RTE agrega 200.200.0.0/16. Aqui estão as tabelas de BGP e de roteamento finais para o RTA, o RTF e o
RTB:

Y Y
 Y Yë Y Y !YYY Y Y   % Y
" Y (Y Y   !YY !YY 2!Y;Yë!Y
DY  !YYY
Y
0
Y (YYY !YYYc !YGYY Y
Y
YYY9-$YYYYYYYYYY9#YA YYYYYYYYYY,Y) 'YE
Y
Y
;DY *   YYYYYY * +YYYYYYYYYYY YYYY YYYYYY
 YY
;D  *  YYYYY  * YYYYYYYYYYY YYYY YYYYYY
 YY
;DY    6 +YYY * +YYYYYYYYYYYYYYYY YYYYYY
 Y% YY
;DY    YYYYY    YYYYYYYYYYYYYYYY YYYYYYYYY+*Y
Y
;DY   % YYYYY    YYYYYYYYYYYYYYYY YYYYYYYYY+*
Y
;D    YYYYY   YYYYYYYYYYY YYYY YYYYYY
Y
Y
Y Ô Y
 (YYY!Y"YY !YYY !Y YY  !Y,YY
 !YYY Y
YYYYYYY YYc !YcYYc Y#!Y0YY0" C!YYY0" CY
YY
YYYYYYYc YY0" CY#Y2 Y !YcYY0" CY#Y2 Y
!YcYYc Y
YYYYYYYYY""!Y) YY""Yë !Y)YY""Yë!Y
;YY
Y'Y
Y
-2Y'Y Y Y Y * +YY-$Y
    Y
Y
YYYYY  *  Y Yë 2Y  !YY   !YY
 $ Y
0YcYYYY  *  Y Y
YYYYYYYYYYY@ 6 <YëY   %!Y (% (!Y
c Y
0YYYYYYY  * %YY
YYYYYYYYYYY@ 6 *<YëY   %!Y (% (!Yc Y
YYYY    Y Y2Y!Y) $ Y
YYYYY    Y Yë 2Y  !YY   !YY
 $ Y
0YYYYYYY    YY
YYYYYYYYYYY@ 6<YëY   %!Y (% (!Yc Y
0YYYYYYY    YY
YYYYYYYYYYY@ 6%<YëY   %!Y (% (!Yc Y
YYYYYYY    Y Y@ 6 <YëY
   !Y (% (Y
YYYY   % Y Y2Y!Yc Y
YYYYY *   Y Yë 2Y  !YY   !YY $ Y
YYYYYYY *   Y  Y@ 6 <YëY * +!Y
(% (+Y
YYYYYYY * + YY Y2Y
!Y" Y
0;cY    6 Y@ 6 <YëY   %!Yc 6 Y
;YYY    Y  Y@ 6 <YëY * +!Y
( (*Y
Y
CY Ô Y
 (YYY!Y"YY !YYY !Y YY  !Y,YY
 !YYY Y
YYYYYYY YYc !YcYYc Y#!Y0YY0" C!YYY0" CY
YY
YYYYYYYc YY0" CY#Y2 Y !YcYY0" CY#Y2 Y
!YcYYc Y
YYYYYYYYY""!Y) YY""Yë !Y)YY""Yë!Y
;YY
Y'Y
Y
-2Y'Y Y Y Y   YY-$Y    Y
Y
YYYYY  *  Y Yë 2Y  !YY   !YY
 $ Y
0YcYYYY  *  Y Y
YYYYYYYYYYY@ 6 <YëY   !Y (%*( !Y" Y
0YYYYYYY  * %YY
YYYYYYYYYYY@ 6 *<YëY   !Y ( ( !Y" Y
YYYYY    Y Yë 2Y  !YY   !YY
 $ Y
0YYYYYYY   % YY
YYYYYYYYYYY@ 6 <YëY   % !Y ( ( !Yc Y
0YcYYYY    Y Y
YYYYYYYYYYY@ 6 <YëY   % !Y ( ( !Y
c Y
YYYYY    Y Yë 2Y  !YY   !YY
 $ Y
0YYYYYYY    YY
YYYYYYYYYYY@ 6+<YëY   !Y ( ( !Y" Y
YYYYYYY    YY Y2Y
!Y" Y
YYYY   % Y Y2Y!Yc Y
YYYYY *   Y Yë 2Y  !YY   !YY $ Y
0YcYYYY *   Y  Y
YYYYYYYYYYY@ 6 <YëY   % !Y (%( !Y
c Y
0YYYYYYY * + YY
YYYYYYYYYYY@ 6%<YëY   % !Y ( ( !Yc Y
0YcY    Y  Y@ 6 <YëY   % !Y
( (%!Y
c Y
0;cY    Y    Y@ 6 <YëY   !Y
( (!Y" Y
,"-YA tabela de roteamento do RTF indica que o modo de alcançar redes locais ao AS300, como
192.208.10.0, é pelo RTB. O modo de alcançar outras redes conhecidas, como 200.200.0.0, é pelo RTA. O
gateway de último recurso é configurado para RTB. Se algo acontecer com a conexão entre o RTB e o RTD,
o padrão que o RTA anuncia entra em ação com uma métrica de 2000.

Y Y
 Y Yë Y Y %!YYY Y Y    Y
" Y (Y Y   !YY !YY 2!Y;Yë!Y
DY  !YYY
Y
0
Y (YYY !YYYc !YGYY Y
Y
YYY9-$YYYYYYYYYY9#YA YYYYYYYYYY,Y) 'YE

Y
;D *   YYYYYY * +YYYYYYYYYYY YYYY YYYYYY
 YY
;DY  *  YYYYY  * YYYYYYYYYYY YYYY YYYYYY
 YY
;D    6 +YYY * +YYYYYYYYYYYYYYYY YYYYYY
 Y% YY
;D    YYYYY   % YYYYYYYYYY YYYY YYYYYY
Y
;D   % YYYYY   % YYYYYYYYYY YYYY YYYYYY
Y
;DY    YYYYY    YYYYYYYYYYYYYYYY YYYYYYYYY+*
Y
Y
Y Ô Y
 (YYY!Y"YY !YYY !Y YY  !Y,YY
 !YYY Y
YYYYYYY YYc !YcYYc Y#!Y0YY0" C!YYY0" CY
YY
YYYYYYYc YY0" CY#Y2 Y !YcYY0" CY#Y2 Y
!YcYYc Y
YYYYYYYYY""!Y) YY""Yë !Y)YY""Yë!Y
;YY
Y'Y
Y
-2Y'Y Y Y Y  * YY-$Y
 *  Y
Y
Y;YYY  *  Y Yë 2Y  !YY   !YY
 $ Y
;YYYYYY  *  Y Y@ 6 <YëY
 * !Y ( (%+Y
YYYYYYY  * %YY Y2Y
!Y" Y
YYYYY    Y Yë 2Y  !YY   !YY
 $ Y
0YYYYYYY   % YY
YYYYYYYYYYY@ 6<YëY    !Y ( (!Y" Y
0YcYYYY    Y Y
YYYYYYYYYYY@ 6 <YëY    !Y ( (% !Y" Y
YYYYY    YY Y  !YY   Y
YYYYYYY   *Y Y2Y!Y) $ Y
YYYYYYY    Y Y2Y!Y" Y
0YYYY   % Y@ 6%<YëY    !Y ( (!Y
" Y
YYYYY *   Y Yë 2Y  !YY   !YY $ Y
0YcYYYY *   Y  Y@ 6 <YëY
    !Y (%+(!Y" Y
0YYYYYYY * + YY
YYYYYYYYYYY@ 6 *<YëY    !Y ( (%!Y" Y
0;cY    6 Y@ 6 <YëY    !Y ( *(!Y
" Y
0YcY    Y  Y@ 6 <YëY    !Y
( (%!Y" Y
 YY !Y  YY "YY#YY

A Comunidade de Suporte Cisco é um fórum onde você poderá fazer e responder perguntas, dar sugestões, e
colaborar com os seus colegas. Abaixo você encontrará algumas das conversas mais recentes e importantes
presentes neste momento no nosso fórum.
Y

Vous aimerez peut-être aussi