BGP

TREINAMENTO AVANÇADO
BGP Design com Roteadores Cisco,

Juniper, Mikrotik, Quagga e Vyatta
 Instrutor: Rinaldo Vaz

 Analista de Redes
Versão do material: 4.1

Última publicação: 08/04/2016
ÚLTIMO TREINAMENTO:
Rio de Janeiro, 04/04 à 08/04 2016
PRÓXIMO TREINAMENTO:
...
 Informações:
https://sites.google.com/site/treinamentobgpmplsv412016/home
treinamento.bgp@gmail.com
2
Versão do material: 4.1 v4.1 | autor: Rinaldo Vaz | treinamento.bgp@gmail.com
1.0
Visão Geral sobre BGP

1. Visão geral sobre BGP
• 1.1 Introdução
• 1.2 Requisitos para se tornar um sistema autônomo
• 1.3 Preenchendo o formulário do Registro.br
• 1.4 Quando utilizar IGP e EGP
• 1.5 Atributos BGP
• 1.6 Entendendo o processo de escolha de rotas
Topologia dos LABs

https://docs.google.com/drawings/d/1NBibvPqAWfw9soB1oWZ9fOEziqKFqFP-zNq_p2OBc2I/edit?usp=sharin
g
3
Versão do material: 4.1 v4.1 | autor: Rinaldo Vaz | treinamento.bgp@gmail.com
1.1 Introdução
 Algumas Características:
1. É um protocolo do tipo “vetor de caminho”
2. As tabelas completas de roteamento são trocadas
entre os dois routers no início da sessão
3. Atualizações adicionais são enviadas imediatamente
através de mensagens de update *
4. Utiliza por padrão a porta TCP 179
*Quando uma nova rota é instalada o router “avisa” imediatamente para seus outros
peers BGP, porém há possibilidade de estabelecer um tempo mínimo (Minimum
Route Advertisement Interval ou MRAI) entre cada rodízio de atualizações,
forçando-o a segurar alguns updates e envia-los de uma só vez em um intervalo
pre-definido. Por exemplo:
neighbor {ip-address | peer-group-name} advertisement-interval seconds

● Fonte:http://www.cisco.com/en/US/docs/ios/iproute_bgp/command/reference/irg_bgp3.html
4
v4.1 | autor: Rinaldo Vaz | treinamento.bgp@gmail.com
1.1 Introdução
 Diferenças entre FIB e RIB:
Fowarding Information Base (FIB)
 Quando um router recebe 2 rotas diferentes para o mesmo
prefixo os critérios de escolha de rota são analisados. A
rota que foi considerada melhor de acordo com os critérios
BGP fica na FIB.
(caso não haja uma rota de melhor metrica estática ou
recebida por outro protocolo de roteamento)
Router Information Base (RIB)
 As rotas que não foram consideradas melhores ficarão
guardadas na RIB e serão utilizadas caso a rota principal
fique indisponível.
 Por padrão, o BGP jamais anuncia uma prefixo que não
esteja na FIB!
5
1.1 Introdução
 Distâncias administrativas:
Outro ponto importante é a distância administrativa, caso 2
prefixos sejam idênticos, o router analisa essa distância, a
menor sempre "ganha". Caso sejam iguais, os critérios
particulares do protocolo de roteamento correspondente
serão analisados:
Padrão Cisco* Padrão Juniper*

Directamente Conectada 0 Directly connected network 0 Router discovery 55
Estática 1 System routes 4 RIP 100
eBGP 20 Static and Static LSPs 5 RIPng 100
EIGRP (Interno) 90 RSVP-signaled LSPs 7 PIM 105
IGRP 100 LDP-signaled LSPs 9 DVMRP 110
OSPF 110 OSPF internal route 10 Aggregate 130
ISIS 115 IS-IS Level 1 internal route 15 OSPF AS external routes 150
RIP 120 IS-IS Level 2 internal route 18 IS-IS Level 1 external route 160
EGP 140 Redirects 30 IS-IS Level 2 external route 165
EIGRP (Externo) 170 Kernel 40 BGP 170
iBGP 200 SNMP 50 MSDP 175
BGP Local 200
Desconhecido 255
6
1.1 Introdução
 A versão corrente do BGP é a versão 4,

especificada na RFC 1771
 É o protocolo responsável por fazer a internet
funcionar da maneira que é
7
1.1 Introdução
 Algumas Características:
1. É um protocolo do tipo “vetor de caminho”
2. As tabelas completas de roteamento são trocadas
entre os dois routers no início da sessão
3. Atualizações adicionais são enviadas imediatamente
através de mensagens de update *
4. Utiliza por padrão a porta TCP 179
*Quando uma nova rota é instalada o router “avisa” imediatamente para seus outros
peers BGP, porém há possibilidade de estabelecer um tempo mínimo (Minimum
Route Advertisement Interval ou MRAI) entre cada rodízio de atualizações,
forçando-o a segurar alguns updates e envia-los de uma só vez em um intervalo
pre-definido. Por exemplo:
neighbor {ip-address | peer-group-name} advertisement-interval seconds

● Fonte:http://www.cisco.com/en/US/docs/ios/iproute_bgp/command/reference/irg_bgp3.html
8
1.1 Introdução
 Mensagens BGP:
– Open (abertura) - É a primeira mensagem enviada por um router que
deseja estabelecer uma sessão com outro, esse por sua vez também
envia uma mensagem open. Após recebidas e checadas*, cada router
envia a primeira mensagem de keep alive e a sessão é estabelecida.
*Mensagens de OPEN contém várias informações sobre o remetente como versão do BGP configurada, número do AS,
routerID, valores de timers configurados entre outros
9
1.1 Introdução
 Mensagens BGP:
– Update (atualização) - É dentro dessas mensagens que vão informações
sobre cada prefixo que está sendo anunciado, uma mensagem de update
também pode conter informações sobre redes que ficaram indisponíveis
e devem ser removidas
Fonte da imagem: http://www.potaroo.net/ispcol/2005-03/fig1.png
10
1.1 Introdução
 Mensagens BGP:
– Notificação (notification message) – É enviada quando uma condição de
erro é detectada; elas são usadas para encerrar uma sessão ativa e
informar a quaisquer roteadores conectados do porque do encerramento
da sessão.
– Sempre que um router envia uma mensagem do tipo notification esse
finaliza imediatamente a sessão BGP correspondente
● Ex: Ao receber uma mensagem de “open” com o número

de AS diferente do que foi configurado localmente, o
router responde imediatamente com uma mensagem
de notification
11
1.1 Introdução
 Mensagens BGP:
– Keep-alive (ainda estou aqui) - De tempo em tempo cada router envia
uma mensagem de keep-alive para que o vizinho saiba que há
conectividade IP. Caso o keep-alive atrase, o router começa a contagem
de hold-time e, se nesse período não for recebido nenhum keep-alive, a
sessão é finalizada. Tanto o tempo de keep-alive como o de hold-time
podem ser configurados para mais ou menos tempo de acordo com o
tipo de link.
– Os valores padrão são 60 segundos de intervalo para keepalive e 180
segundo de tolerância (hold time) que podem ser alterados com o
seguinte comando:
!
router bgp 65001
neighbor 192.168.2.1 timers 20 60
!
– Com esse comando, o tempos de keepalive e hold time ficariam setados
em 20 e 60 segundos respectivamente
12
1.2
Requisitos para se tornar

um Sistema Autônomo
13
1.2 - Requisitos para se tornar um sistema
autônomo
 Uma organização justifica a designação de
um ASN quando apresenta uma das
seguintes necessidades:
– Multi Provedor: Quando a organização está conectada a dois ou
mais provedores de transito Internet distintos e independentes e
necessita, portanto, fazer uso de protocolos de roteamento
dinâmico
– Política única de roteamento: Quando a organização possui uma
política de roteamento que é distinta daquela aplicada pelo(s)
provedor(es) de transito Internet.
Mais informações em:

http://registro.br/provedor/numeracao/regras.html
14
1.3
Preenchendo o Formulário do
registro.br
15
1.3 - Preenchendo o Formulário do
registro.br
 Há um formulário simples que pode ser baixado
no seguinte endereço:
http://registro.br/provedor/numeracao/pedido-form.txt
 Em caso de dúvidas há um arquivo contento

informações de ajuda:
http://registro.br/provedor/numeracao/pedido-ajuda.txt
 Informações completas em:

http://registro.br/provedor/numeracao/faq.html
16
1.4
Quando utilizar
IGP e EGP
17
1.4 - Quando utilizar IGP e EGP
 O BGP foi desenvolvido para troca de rotas

entre Sistemas Autônomos distintos
– Não há nenhum motivo para um provedor de serviços utilizar
BGP se esse não possuir um ASN.
– A finalidade do BGP é permitir que os IPs do Sistema Autônomo
apareçam na internet.
– Tecnicamente nada impede de utilizar BGP com apenas uma
operadora, porém é um requisito para obter um ASN:
18
1.4 - Quando utilizar IGP e EGP
 Caso um dos clientes do provedor também seja

um Sistema Autônomo é indispensável a
utilização do BGP com o cliente e operadoras
de trânsito.
19
1.5
Atributos BGP
20
1.5 - Atributos BGP
 Conhecidos obrigatórios (Well-known mandatory):

Além de obrigatório em todas as implementações,
precisam estar em todas as mensagens de update
trocadas entre os roteadores via BGP.
 Conhecidos discricionários (Well-known discretionary):

Semelhantes aos obrigatórios, porém não precisam estar
contidos em todas as mensagens de update. Todas as
implementações precisam suporta-los
21
1.5 - Atributos BGP
 Opcional transitivo (Optional transitive):

Não precisam ser implementados por todos
os fabricantes, e quando sim, podem ser “propagados”
para outros neighbors através de mensagens de update.
 Opcional não-transitivo (Optional non-transitive):

Semelhantes aos citados acima, porém, um router nunca
“propaga” esses atributos para outro neighbor.
22
1.5 - Atributos BGP
 Uma boa descrição pode ser encontrada no livro:

“CCNP BSCI - Official Exam Certification Guide,
4th edition” de Brent Steward:
23
1.6
Entendendo o Processo de
Escolha de Rotas
24
1.6 - Entendendo o processo de escolha de
rotas
 Em primeiro lugar, o BGP apenas analisa os atributos

para "desempatar" duas ou mais rotas para o MESMO
PREFIXO.
 Caso haja um prefixo mais específico esse sempre será

preferido independentemente dos seus atributos "mais
favoráveis".
25
rotas
 Como o BGP escolhe uma rota:

 Sempre que houverem duas ou mais opções de rota para prefixos iguais (mesma máscara de sub-rede) e
ambas tiverem sido recebidas via BGP, o protocolo vai escolher a melhor rota de acordo com a ordem:
1. Rota com maior valor de WEIGHT (Cisco, Quagga, RouterOS, OpenBGPD)

2. Rota com maior valor de LOCAL_PREF
3. Rota originada localmente (bgp network)
4. Rota com o menor AS_PATH.
5. Rota com menor tipo de origem.
IGP (i) < EGP (e) < INCOMPLETE (?)
6. Rota com menor métrica multi-exit discriminator (MED).
7. Escolhe a rota recebida por (eBGP) em relação a uma (iBGP).
26
rotas
 Como o BGP escolhe uma rota:
8. Rota com a menor métrica IGP para o nexthop BGP
Ex: O next-hop aprendido via OSPF vai ”vencer” um next-hop
aprendido via ISIS
9. Rota externa mais antiga
10. Rota recebida de um router com menor Router ID
11. Rota com o menor tamanho de cluster list. (Ambientes com Route
Reflector apenas)
12. Rota com o menor endereço de neighbor
 A análise segue para o próximo critério apenas quando há
empate no critério atual, assim, o tamanho do AS PATH só
será analisado caso o valor de weight e local preference
sejam os mesmos para as duas rotas.
27
1.6
PERGUNTAS?
28
2.0
Primeiros Passos
para Aparecer na Internet
2. Primeiros Passos para Aparecer na Internet
• 2.1-Configurando BGP com apenas um link
• 2.2-Analisando as rotas recebidas
• 2.3-Configurando BGP com 2 links
• 2.4-Utilizando um Looking Glass
• 2.5-Fail-Over automático
• 2.6-Escolhendo o melhor link
• 2.7-Balanceamento de links
• 2.8-Implementando alta disponibilidade com VRRP
• 2.9-BGP Timers
29
2.1
Configurando BGP com

apenas um link
30
2.1-Configurando BGP com apenas um link
 Antes de começar, vamos entender o cenário no ponto de
vista geral, onde cada aluno é dono de um AS:
CENARIO 1-1
AS1
AS1
AS1 AS1
AS2
AS4
AS3
LAB 1-1-1 31
2.3 Configurando BGP com 2 links
 Nesse LAB, receberemos mais um link (AS 200) através da
interface s1/0:
!-- lembrando que X é o número do AS do aluno
LAB 1-2-1 32
 Nesse LAB, cada aluno possui um Cisco 3660 com uma
placa serial modelo NM-4T conectado ao AS 100 na
interface s1/1 e uma fast ethernet conectada ao switch da
sala do curso.
 O “X” deve ser entendido como o AS do aluno (1 até 16).
AS-100
.1
100.X.1.0/30
E1/0 .2
AS-X-R1
F0/0 .254
X.128.0.0/9
.1
LAB 1-1-1 33
 O router de cada grupo responde pelo IP X.128.0.254/9

(onde X é o número do grupo).
 Para acessá-lo, configurem nos seus laptops um IP dentro
dessa mesma rede preferencialmente .1 e gateway
padrão X.128.0.254.
 Verifiquem a conectividade IP e em caso positivo abram
uma sessão telnet com esse equipamento:
ALUNO@notebook# telnet X.128.0.254
Trying X.128.0.254... Para quem usa windows pode usar o Putty......
Connected to X.128.0.254. http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Escape character is '^]'.

User Access Verification
Password: A senha de acesso é 123 Onde X é o número do seu AS
LAB 1-1-1 34
 Estamos agora no modo ”usuário”:

AS-X-R1>
 Para iniciar as configurações precisaremos inicialmente

entrar no modo ”privilegiado”, e será exigida uma outra
senha:
AS-1-R1>enable
Password: 123
AS-X-R1#
 E em seguida no modo de configuração ”global”:

AS-X-R1#terminal monitor
AS-X-R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
AS-X-R1(config)#
LAB 1-1-1 35
 O router de cada grupo responde pelo IP X.128.0.254/9

(onde X é o número do grupo).
 Para acessá-lo, configurem nos seus laptops um IP dentro
dessa mesma rede preferencialmente .1 e gateway
padrão X.128.0.254.
uma sessão telnet com esse equipamento:
Trying X.128.0.254... Para quem usa windows pode usar o Putty......
Connected to X.128.0.254. http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Onde X é o número do seu AS
Password: A senha de acesso é 123
LAB 1-1-1 36
 O primeiro passo na configuração BGP é adicionar

um neighbor (peer):
AS-X-R1(config)# router bgp X

AS-X-R1(config-router)# neighbor 100.X.1.1 remote-as 100
AS-X-R1(config-router)# neighbor 100.X.1.1 description eBGP com as 100
!--- Se digitar errado e o sistema “aceitar” o comando,
!--- digite o mesmo comando com “no” antes.
!--- Ex: neighbor 100.x.1.1 remote-as 101
!--- no neighbor 100.x.1.1 remote-as 101
!--- no neighbor 100.x.1.1 (remove tudo)
AS-X-R1(config-router)#
Jan 20 15:32:02.915: %BGP-5-ADJCHANGE: neighbor 100.X.1.1 Up
LAB 1-1-1 37
 Verificando o status da sessão BGP recém-criada:
AS-X-R1#sh ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
100.X.1.1 4 100 7 4 4 0 0 00:00:02 8
LAB 1-1-1 38
 Como realizar a mesma configuação

no JunOS e RouterOS
router> configure
router# set routing-options autonomous-system X
router# set protocols bgp group AS100 type external
router# set protocols bgp group AS100 export Interno
router# set protocols bgp group AS100 peer-as 100
router# set protocols bgp group AS100 neighbor 100.X.1.1
[admin@mikrotik] > /routing bgp instance

[admin@mikrotik] /routing bgp instance>
set default as=X
/routing bgp peer
[admin@mikrotik] /routing bgp peer>
add name=AS100 remote-address=100.X.1.1 remote-as=100
LAB 1-1-1 39
 Verificando os anúncios que recebo da minha operadora:
AS-X-R1#show ip bgp neighbors 100.X.1.1 routes

Network Next Hop Metric LocPrf Weight Path...
*> 100.0.0.0 100.X.1.1 0 100 i
*> 123.0.0.0 100.X.1.1 0 100 111 55 123 i
…
 Posteriormente veremos na prática a diferença entre os
comandos com ”received-routes” e apenas ”routes” no
final.
LAB 1-1-1 40
 Agora todos tentam ping para 123.123.123.1 a partir do seu

router:
AS-X-R1>ping 123.123.123.1
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/84/96 ms
AS-X-R1>
 Agora um Traceroute...
LAB 1-1-1 41
 Agora um Traceroute...
AS-X-R1>traceroute 123.123.123.1

Tracing the route to 123.123.123.1
1 100.X.1.1 [AS 100] 16 msec 12 msec 16 msec

2 111.100.1.1 [AS 111] 60 msec 48 msec 44 msec
3 111.111.1.1 [AS 111] 68 msec 44 msec 68 msec
4 55.111.1.1 [AS 55] 100 msec 80 msec 88 msec
5 55.55.1.1 [AS 55] 116 msec 108 msec 108 msec
6 123.55.1.1 [AS 123] 104 msec 101 msec 108 msec
LAB 1-1-1 42
 Em seguida ping para 123.123.123.1 a partir do seu laptop

Sucesso??
rinaldo@laptop:~$ traceroute 123.123.123.1 -n

traceroute to 123.123.123.1 (123.123.123.1), 30 hops max, 60 byte packets
1 X.128.0.254 5.646 ms 15.595 ms 25.613 ms
2 ***
3 ***
4 ***
5 ***
6 ***
7 *^C
 Que problema pode estar havendo?

LAB 1-1-1 43
 Esse ponto merece uma pausa para analisar algo

importante no ”Troubleshooting”.
 Ao executar um traceroute um host verifica a sua tabela de

roteamento, caso não haja ocorrências os pacotes do
traceroute são encaminhados pela rota padrão, não sendo
nada especificado no comando, o IP de origem é sempre o
mesmo da interface conectada ao ”next-hop”.
 Em nosso LAB qual o next-hop para 123.123.123.1 ?

Provavelmente 100.X.1.1, qual IP o router vai utilizar
como origem?
LAB 1-1-1 44
 O IP de origem é 100.X.1.2 que por sua vez está dentro de

uma rede ”conhecida” pelo looking glass (123.123.123.1).
 Já o laptop não consegue alcançar o destino porque o seu IP

de origem é X.128.0.1, rede que não é conhecida pelo
looking glass já que ainda não anunciamos nada.
 Não se trata então de o laptop ”não conseguir alcançar”

123.123.123.1, na verdade os pings disparados pelo
laptop chegam ao seu destino, porém o destino não sabe
para quem responder.
LAB 1-1-1 45
 O segundo passo é anunciar o classe A (bloco /8) do seu

grupo:
!--- entra no modo de configuração BGP
AS-X-R1(config-router)#network X.0.0.0 mask 255.0.0.0
!--- adiciona a rede x.0.0.0 para ser anunciada a partir desse router
AS-X-R1(config-router) auto-summary
!--- permite que o BGP anuncie x.0.0.0/8 bastando com que haja qualquer
!--- IP/rotaFIB dentro das redes declaradas em networks
AS-X-R1(config-router)#end
!--- volta ao modo privilegiado
AS-X-R1# clear ip bgp 100.X.1.1
!--- reinicia a sessão BGP ==> OPCIONAL
LAB 1-1-1 46
 Auto-Summary:
 Quando habilitamos o auto-summary, o BGP vai sumarizar na classe

padrão (classe A, B ou C) os prefixos declarados em network ou
redistribute
 Algumas literaturas afirmam que o auto-summary não funciona com

prefixos anunciados via comando “network”. É possível que isso ocorra
em versões mais antigas do IOS, porém como podemos ver nesse LAB
(IOS 12.4), temos um IP /32 em uma interface loopback, que por sua vez
é sumarizado e redistribuído como uma classe A
 É importante lembrar que esse tipo de sumarização ocorre apenas para

classes PADRÃO, e muito dificilmente será utilizado em produtividade.
LAB 1-1-1 47
 Agora verifico os anúncios que estou fazendo para o AS 100:
AS-X-R1#sh ip bgp neighbors 100.X.1.1 advertised-routes

BGP table version is 15, local router ID is 100.X.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> X.0.0.0 0.0.0.0 0 32768 i
 Caso apareça algo parecido com isso, vamos testar novamente a

conectividade IP com o looking glass a partir do laptop.
LAB 1-1-1 48
 Nova tentativa após anúncio do prefixo X.0.0.0/8
rinaldo@laptop:~$ traceroute 123.123.123.1 -n

1 X.128.0.254 9.231 ms 19.290 ms 29.389 ms
2 100.X.1.1 39.495 ms 49.618 ms 59.774 ms
3 111.100.1.1 120.506 ms 140.731 ms 150.869 ms
4 111.111.1.1 181.203 ms 201.430 ms 211.495 ms
5 55.111.1.1 231.679 ms 232.583 ms 232.696 ms
6 55.55.1.1 253.021 ms 253.010 ms 252.910 ms
7 123.55.1.1 273.051 ms 231.043 ms 321.238 ms
 SUCESSO!!
LAB 1-1-1 49
 Sintam-se à vontade para entrar no looking glass e executar

testes de PING e TRACEROUTE!
LAB 1-1-1 50
2.1
PERGUNTAS?
51
2.2
Analisando as rotas
recebidas
52
2.2-Analisando as rotas recebidas
 Vamos detalhar melhor as rotas recebidas:

AS-X-R1>sh ip bgp summary
...
100.X.1.1 4 100 112 83 22 0 0 01:06:03 3
 Esse comando mostra todas as sessões BGP configuradas

ativas e não ativas.
 Nesse laboratório apenas uma sessão está configurada.
 Vamos entender o que cada campo significa...
53
 Entendendo os campos do summary:
100.X.1.1 4 100 112 83 22 0 0 01:06:03 3
 Neighbor = 100.X.1.1
 Esse é o IP do router remoto (configurado em router BGP X).
54
100.X.1.1 4 100 112 83 22 0 0 01:06:03 3
 V=4
 Versão do BGP utilizada nessa sessão.
55
100.X.1.1 4 100 112 83 22 0 0 01:06:03 3
 AS = 100
 AS do neighbor remoto (configurado em neighbor 100.X.1.1
remote-as X).
56
100.X.1.1 4 100 112 83 22 0 0 01:06:03 3
 MsgRcvd = 112
 MsgSent = 83
 Quantidade total de mensagens BGP recebidas e enviadas
incluindo ”keepalives” e ”updates”.
57
100.X.1.1 4 100 112 83 22 0 0 01:06:03 3
 TblVer = 22
 Versão atual da tabela de rotas BGP, sempre que uma nova rota é
inserida ou removida o TblVer é incrementado.
58
100.X.1.1 4 100 112 83 22 0 0 01:06:03 3
 InQ = 0
 OutQ = 0
 Updates na fila de entrada e de saída.
59
100.X.1.1 4 100 112 83 22 0 0 01:06:03 3
 Up/Down = 01:06:03
 Contador das horas minutos e segundos desde de que a sessão
foi estabelecida ou que a sessão ficou down, após 24 horas o
contador muda para 1d00h00m (dias/horas/minutos) após
uma semana 01w0d00h (semanas/dias/horas).
 Antes de uma sessão estabelecer ao menos uma vez o
contador fica em ”never”.
60
100.X.1.1 4 100 112 83 22 0 0 01:06:03 3
 State/PfxRcd = 3
 Esse campo merece uma atenção especial pois será o mais
frequentemente observado. Indica o estado da conexão BGP.
● Nesse caso está contando 3 prefixos, mas existem 5
estados possíveis, IDLE, CONECT, ACTIVE, OPENSENT,
OPENCONFIRM e ESTABLISHED, iremos entender melhor
cada um desses estados nos próximos slides.
61

State/PfxRcd
IDLE
 É o estado em que a sessão fica quando é interrompida por uma mensagem de notificação ou
intervenção do administrador, esse estado, quando se prolonga por muito tempo, aponta
algum possível problema de conectividade IP ou ainda que o BGP não foi configurado
corretamente do lado remoto.
62

State/PfxRcd
ACTIVE
 ACTIVE: O BGP tenta estabelecer comunicação com um peer inicializando uma conexão
TCP. Caso esta seja bem sucedida, passa-se ao estado OPENSENT. Se esta tentativa
não for bem sucedida, pelo motivo de expiração do tempo, por exemplo, o estado passa
para CONNECT. Em cada interrupção pelo sistema ou pelo administrador, volta ao estado
IDLE. Geralmente as transições entre o estado de CONNECT e ACTIVE refletem
problemas no nível TCP.
63

State/PfxRcd
CONNECT
 Neste estado o BGP aguarda pela conexão TCP, com destino na porta 179. Quando a
conexão estiver estabelecida, ou seja, com o recebimento da mensagem de OPEN, passa-
se ao estado de OPENSENT. Se a conexão nível de transporte não for bem sucedida, o
estado vai para ACTIVE. No caso do tempo de espera ter sido ultrapassado, o estado
volta para CONNECT. Em qualquer outro evento o estado retorna para IDLE.
64

State/PfxRcd
OPEN SENT
 OPENSENT: Neste estado o BGP aguarda pela mensagem de OPEN e faz uma checagem de
seu conteúdo. Caso seja encontrado algum erro como número de AS incoerente ao
esperado ou a própria versão do BGP, envia-se uma mensagem tipo NOTIFICATION e
volta ao estado de IDLE. Caso não ocorram erros na checagem, inicia-se o envio de
mensagens KEEPALIVE. Em seguida, acerta-se o tempo de Hold Time, sendo optado o
menor tempo entre os dois peers. Depois deste acerto, compara-se o número AS local e o
número AS enviado pelo peer, com o intuito de detectar se é uma conexão iBGP (números
de AS iguais) ou eBGP (números de AS diferentes). Em caso de desconexão a nível TCP,
o estado passa para ACTIVE. Para as demais situações de erro, como expiração do Hold
Time, envia-se uma mensagem de NOTIFICATION com o código de erro correspondente e
retorna-se ao estado de IDLE. No caso de intervenção do administrador ou o próprio
sistema, também retorna-se o estado IDLE.
65

State/PfxRcd
OPEN CONFIRM
 OPENCONFIRM: Neste estado o BGP aguarda pela mensagem de KEEPALIVE e quando
esta for recebida, o estado segue para ESTABLISHED e a negociação do peer é
finalmente concluída. Com o recebimento da mensagem de KEEPALIVE, é acertado o
valor negociado de Hold Time entre os peers. Se o sistema receber uma mensagem tipo
NOTIFICATION, retorna-se ao estado de IDLE. O sistema também envia periodicamente,
segundo o tempo negociado, mensagens de KEEPALIVE. No caso da ocorrência de
eventos como desconexão ou intervenção do operador, retorna-se ao estado de IDLE
também. Por fim, na ocorrência de eventos diferentes aos citados, envia-se uma
mensagem NOTIFICATION, retornando ao estado de IDLE.
66

State/PfxRcd
ESTABLISHED
 ESTABLISHED: Neste estado, o BGP inicia a troca de mensagens de UPDATE ou
KEEPALIVE, de acordo com o Hold Time negociado. Caso seja recebida alguma
mensagem tipo NOTIFICATION, retorna-se ao estado IDLE. No recebimento de cada
mensagem tipo UPDATE, aplica-se uma checagem por atributos incorretos,
inconsistentes, duplicados, ou mesmo faltando, caso algum erro seja detectado, envia-se
uma mensagem de NOTIFICATION, retornando ao estado IDLE. Por fim, se o Hold Time
expirar ou for detectada desconexão ou intervenção do administrador, também retorna-se
ao estado de IDLE.
67

State/PfxRcd
3
 Esse número não representa a quantidade de prefixos recebidos de um

neighbor, mas sim a quantidade de prefixos que foram parar na RIB
após terem passado pelos filtros.
 Um State/PfxRcd 0 não significa necessariamente que não estou
recebendo nenhuma rota, por exemplo, pode ser que o next-hop dessas
rotas seja inalcançável pelo meu router e assim elas não aparecem.
Detalharemos esses casos posteriormente.
68
Fonte: http://upload.wikimedia.org/wikipedia/commons/thumb/a/a8/BGP_FSM.svg/549px-BGP_FSM.svg.png
69
 Vamos detalhar todas as rotas BGP:

AS-X-R1# show ip bgp
BGP table version is 22, local router ID is 100.X.1.2
*> 6.0.0.0 100.X.1.1 0 100 6 i
*> 100.0.0.0 100.X.1.1 0 100 i
*> 123.0.0.0 100.X.1.1 0 100 222 123 i

(...)
 Esse comando mostra todas as rotas recebidas via BGP, tanto as

escolhidas (FIB) como também as não escolhidas (RIB). Como
recebemos rotas de apenas um peer, não há rotas ”não escolhidas”
70
 Vamos detalhar uma rota específica:

AS-X-R1#sh ip bgp 123.0.0.0
BGP routing table entry for 123.0.0.0/8, version 10
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x208
Not advertised to any peer
100 111 55 123
100.X.1.1 from 100.X.1.1 (100.0.0.100)

Origin IGP, localpref 100, valid, external, best
✔ Esse comando detalha as rotas para o prefixo 123.0.0.0/8, e caso outras rotas para esse mesmo
prefixo tenham sido recebida via BGP de outro(s) neighbor(s), mais entradas semelhantes
aparecerão uma abaixo da outra.
 Entenderemos cada campo a seguir...
71
 Vamos detalhar uma rota em específico:

...
 Essa linha mostra a versão da routing table descrita nos
slides anteriores.
72

...
 Paths significa a quantidade de neighbors que me enviaram rotas para
esse mesmo prefixo, ou seja, ”1 avaliable” diz que apenas 1 neighbor
me enviou.
 ”best #1” a rota que foi escolhida (na ordem de cima para baixo) de acordo
com os critérios do BGP – weigh, local_pref, etc.
 ”table Default-IP-Routing-Table” significa que as rotas estão na FIB padrão.
Múltiplas FIB's são usadas com VRF.
73

GX-R1#sh ip bgp 123.0.0.0
...
Flag: 0x208
...
74

...
...
 Essa mensagem significa que esse prefixo 123.0.0.0/8 não está
sendo anunciada via BGP para nenhum neighbor. Na verdade
qualquer rota nesse laboratório aparecerá com essa
mensagem.
 Esse campo será detalhado posteriormente na sessão ”AS de
trânsito”.
75

...
100 111 55 123
...
 AS-PATH: mostra da direita para a esquerda o AS que originou essa rota
e todos os ASs no caminho.
 Ou seja, o AS 123 originou o anúncio para o AS 55 que recebeu,
considerou como melhor rota e exportou para o AS 111, depois para o
AS 100, o qual também considerou como melhor e repassou para meu
AS.
 Um ponto importante a se observar é que mesmo que um AS tenha mil
caminhos para um determinado prefixo, é apenas UM que ele vai
escolher como ”BEST #” e passar adiante (por padrão).
76

...
100.X.1.1 from 100.X.1.1 (100.0.0.100)
...
 O primeiro IP dessa linha significa o ”next-hop”(próximo salto)
para esse prefixo, caso o next-hop não esteja contido em uma
rota válida da FIB, esse jamais será eleito como ”BEST”.
 O segundo IP dessa linha me diz o endereço do ”neighbor” que
me enviou essa rota via BGP.
 O IP (X.X.X.X) é na verdade o ”router-ID” desse neigbor descrito
acima.
77
2.2
PERGUNTAS?
78
2.3
Configurando BGP com 2

links
(MULTIHOMING)
79
 Os próximos Laboratórios (1-2-1 e 1-2-2) utilizarão esse
cenário, e dessa vez, temos link também com o AS 200:
LAB 1-2-1 80
 Nesse LAB, receberemos mais um link (AS 200) através da
interface G1/0:
!-- lembrando que X é o número do AS do aluno
AS-100 AS-200
.1 .1
100.X.1.0/30 . 0/30
0. X .1
G1/0 .2 .2 20
G2/0
AS-X-R1
F0/0 .254
X.128.0.0/9
.1
LAB 1-2-1 81
 Primeiro passo é a configuração do próximo neighbor:

AS-X-R1(config-router)# neighbor 200.X.1.1 description eBGP com as 200
*Jan 20 16:04:54.775: %BGP-5-ADJCHANGE: neighbor 200.1.1.1 Up
LAB 1-2-1 82
 Verificando o status das sessões BGP recém-criadas:

AS-X-R1#sh ip bgp summary
100.1.1.1 4 100 192 170 9 0 0 00:27:48 7
200.1.1.1 4 200 191 181 9 0 0 00:27:51 7
 O número de PfxRcd vai ser maior a medida que os alunos estabeleceram

suas conexões.
LAB 1-2-1 83
 Detalhando as rotas recebidas via BGP

 Note que algumas rotas tem “2 opções” e outras não...
AS-X-R1>show ip bgp
BGP table version is 16, local router ID is 1.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale

*> 1.0.0.0 0.0.0.0 0 32768 i
* 2.0.0.0 200.1.1.1 0 200 2 i
*> 100.1.1.1 0 100 2 i
* 55.0.0.0 200.1.1.1 0 200 222 123 55 i
*> 100.1.1.1 0 100 111 55 i
*> 100.0.0.0 100.1.1.1 0 100 i
*> 111.0.0.0 100.1.1.1 0 100 111 i
*> 123.0.0.0 200.1.1.1 0 200 222 123 i
* 100.1.1.1 0 100 111 55 123 i
*> 123.123.0.0/16 200.1.1.1 0 200 222 123 i
*> 123.123.123.0/24 200.1.1.1 0 200 222 123 i
*> 200.0.0.0/8 200.1.1.1 0 200 i
*> 222.0.0.0/8 200.1.1.1 0 200 222 i
LAB 1-2-1 84

 Como temos BGP com duas operadoras, o normal seria
receber os prefixos das duas operadoras certo?
LAB 1-2-1 85

 Como temos BGP com duas operadoras, o normal seria
receber os prefixos das duas operadoras certo?
NEM SEMPRE!
LAB 1-2-1 86
 Outros prefixos seguirão o mesmo comportamento mas

vamos focar no prefixo 222.0.0.0/8 do AS 222:
AS-X-R1#show ip bgp 222.0.0.0

Advertised to update-groups:
1
200 222
200.X.1.1 from 200.X.1.1 (200.0.0.100)
 De acordo com o resultado acima esse prefixo só está sendo

recebido pelo lado do AS 200
LAB 1-1-1 87

 O que significa essas o fato de algumas ”rotas alternativas”
desaparecerem até da RIB?
 E o que isso implica na prática?
 Por enquanto o importante à saber é que esse router passou a ser

”trânsito” dos AS's 200 e 222 para alcançar o AS 100,111 e
todos os seus ”downstreams”.
 No caso desse router ficar down, outro AS ficará na mesma
situação... vamos ver quem logo adiante, mas antes entender
esse processo
LAB 1-2-1 88
 Veja como os anúncios se preopagam...
AS123
AS55
222.0.0.0/8
AS222
AS111
AS-100-BKB
AS100 AS200
AS-100-RX
ASX
LAB 1-2-1 89
AS123
AS55
222.0.0.0/8
AS222
AS111
AS-100-BKB
AS100 AS200
AS-100-RX
ASX
LAB 1-2-1 90
AS123
AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
AS111
AS-100-BKB
AS100 AS200
Prefixo ASPATH
AS-100-RX *>222.0.0.0/8 222
ASX
LAB 1-2-1 91
AS123
AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
AS111
AS-100-BKB
AS100 AS200
Prefixo ASPATH
AS-100-RX *>222.0.0.0/8 222
ASX
LAB 1-2-1 92
AS123
AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
AS111
AS-100-BKB
AS100 AS200
Prefixo ASPATH
AS-100-RX *>222.0.0.0/8 222
ASX
LAB 1-2-1 93
AS123
Prefixo ASPATH
*>222.0.0.0/8 123 222 AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
AS111
AS-100-BKB
AS100 AS200
Prefixo ASPATH
AS-100-RX *>222.0.0.0/8 222
Prefixo ASPATH ASX

*>222.0.0.0/8 200 222
LAB 1-2-1 94
AS123
Prefixo ASPATH
*>222.0.0.0/8 123 222 AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
AS111
AS-100-BKB
AS100 AS200
Prefixo ASPATH
AS-100-RX *>222.0.0.0/8 222
Prefixo ASPATH ASX

*>222.0.0.0/8 200 222
LAB 1-2-1 95
AS123
Prefixo ASPATH
*>222.0.0.0/8 123 222 AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
Prefixo ASPATH
*>222.0.0.0/8 55 123 222 AS111
AS-100-BKB
AS100 AS200
Prefixo ASPATH
*>222.0.0.0/8 X 200 222 Prefixo ASPATH
AS-100-RX *>222.0.0.0/8 222
Prefixo ASPATH ASX

*>222.0.0.0/8 200 222
LAB 1-2-1 96
AS123
Prefixo ASPATH
*>222.0.0.0/8 123 222 AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
Prefixo ASPATH
*>222.0.0.0/8 55 123 222 AS111
* 222.0.0.0/8 100 X 200 222
AS-100-BKB
AS100 AS200
Prefixo ASPATH
*>222.0.0.0/8 X 200 222 Prefixo ASPATH
* 222.0.0.0/8 111 55 123 222 AS-100-RX *>222.0.0.0/8 222
Prefixo ASPATH ASX

*>222.0.0.0/8 200 222
LAB 1-2-1 97
 Evitando se tornar AS de trânsito dos meus UPSTREAMS

 Fazer anúncios faz do meu router um potencial provedor de
trânsito das redes que anuncio (dependendo da origem).
AS-X-R1>sh ip bgp neighbors 100.X.1.1 advertised-routes
...
*> X.0.0.0 0.0.0.0 0 32768 i
...

...
*> X.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 100.1.1.1 0 100 2 i
*> 55.0.0.0 100.1.1.1 0 100 111 55 i
*> 100.0.0.0 100.1.1.1 0 100 i
*> 111.0.0.0 100.1.1.1 0 100 111 i
...
LAB 1-2-1 98
 Implementando filtros de saída em meus upstreams

 Há várias maneiras e vamos iniciar pela mais simples:
1)Criando uma prefix-list:

AS-X-R1(config)#ip prefix-list MEUS-BLOCOS permit X.0.0.0/8
!--- adiciona o bloco do AS do grupo na lista ”MEUS-BLOCOS”
AS-X-R1(config)#router bgp X
AS-X-R1(config-router)#neighbor 200.X.1.1 prefix-list MEUS-BLOCOS out
!---aplicar o mesmo filtro na saída do AS 200
!--- aplicar o mesmo filtro na saída do AS 100
AS-X-R1#clear ip bgp *
LAB 1-2-1 99
 Verificando as rotas recebidas após o filtro de

saída
● Agora o router anuncia para os UPSTREAMS apenas o
necessário que é o prefixo /8 correspondente ao grupo:
BGP table version is 24, local router ID is X.0.0.1

*> X.0.0.0 0.0.0.0 0 32768 i


*> X.0.0.0 0.0.0.0 0 32768 i
LAB 1-2-1 100

AS123
AS55
222.0.0.0/8
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 101
AS123
AS55
222.0.0.0/8
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 102
AS123
AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
AS111
AS100 AS200
Prefixo ASPATH
*>222.0.0.0/8 222
ASX
LAB 1-2-1 103
AS123
AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
AS111
AS100 AS200
Prefixo ASPATH
*>222.0.0.0/8 222
ASX
LAB 1-2-1 104
AS123
Prefixo ASPATH
*>222.0.0.0/8 123 222 AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
AS111
AS100 AS200
Prefixo ASPATH
*>222.0.0.0/8 222
Prefixo ASPATH ASX

*>222.0.0.0/8 200 222
LAB 1-2-1 105
AS123
Prefixo ASPATH
*>222.0.0.0/8 123 222 AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
AS111
AS100 AS200
Prefixo ASPATH
*>222.0.0.0/8 222
Filtros de saída
Prefixo ASPATH ASX

*>222.0.0.0/8 200 222
LAB 1-2-1 106
AS123
Prefixo ASPATH
*>222.0.0.0/8 123 222 AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
Prefixo ASPATH
*>222.0.0.0/8 55 123 222 AS111
AS100 AS200
Prefixo ASPATH
*>222.0.0.0/8 222
Prefixo ASPATH ASX

*>222.0.0.0/8 200 222
LAB 1-2-1 107
AS123
Prefixo ASPATH
*>222.0.0.0/8 123 222 AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
Prefixo ASPATH
*>222.0.0.0/8 55 123 222 AS111
AS100 AS200
Prefixo ASPATH
Prefixo ASPATH
*> 222.0.0.0/8 111 55 123 222
*>222.0.0.0/8 222
Prefixo ASPATH ASX

*>222.0.0.0/8 200 222
LAB 1-2-1 108
AS123
Prefixo ASPATH
*>222.0.0.0/8 123 222 AS55
Prefixo ASPATH
*>222.0.0.0/8 222 222.0.0.0/8
AS222
Prefixo ASPATH
*>222.0.0.0/8 55 123 222 AS111
AS100 AS200
Prefixo ASPATH
Prefixo ASPATH
*> 222.0.0.0/8 111 55 123 222
*>222.0.0.0/8 222
Prefixo ASPATH ASX

*>222.0.0.0/8 200 222
LAB 1-2-1 * 222.0.0.0/8 100 111 55 123 222
109
2.3
PERGUNTAS?
110
2.4
Utilizando um
Looking Glass
111
2.4 Utilizando um Looking Glass
 Um looking glass nada mais é do que um router com acesso

público em algum lugar da internet, em sua maioria, a
interface é web para facilitar a vida do usuário, mas é o
mesmo que entrar nesse router e executar certos
comandos como:
show ip bgp x.x.x.x, ping x.x.x.x, traceroute x.x.x.x
Um dos mais famosos é o Hurricane Eletric...
http://lg.he.net
112
113
114
 Em nosso LAB o Looking glass é 123.123.123.1, vamos

primeiramente verificar a conectividade com esse
endereço:
ALUNO@notebook:~$ traceroute 123.123.123.1 -n
1 X.128.0.254 5.292 ms 5.655 ms 5.640 ms
2 200.X.1.1 13.807 ms 14.198 ms 100.701 ms
3 222.200.10.1 92.724 ms 92.302 ms 69.351 ms
4 222.222.1.1 127.492 ms 73.505 ms 69.707 ms
5 123.222.2.1 43.309 ms 78.401 ms 66.332 ms
*Clientes Windows utilizam ”tracert 123.123.123.1”
 O que podemos concluir com esse traceroute?
 Meus pacotes entram no AS 200, depois no AS 222 e chegam ao seu destino.
115
 Qual critério o meu router (primeiro salto) utilizou para

considerar esse caminho como melhor?
 Vamos entender:
AS-X-R1>sh ip bgp 123.123.123.1
100 111 55 123
100.X.1.1 from 100.X.1.1 (100.100.100.1)
Origin IGP, localpref 100, valid, external
200 222 123
200.X.1.1 from 200.X.1.1 (200.200.200.1)
 Notem que em nenhuma das rotas há qualquer valor no
atributo "weight" que é o primeiro critério, em segundo é
verificado o "localpref" que nos dois casos está em 100
(empate), o algoritmo de seleção de rotas segue então
para o próximo "critério de desempate" (menor AS Path)
onde a rota #2 foi mais feliz.
116
#Conectar-se ao looking Glass
ALUNO@notebook:~$ telnet 123.123.123.1

...
AS-123-R1>traceroute X.128.0.1
Tracing the route to X.128.0.1
1 123.222.2.2 8 msec 8 msec 12 msec
2 222.222.1.2 [AS 222] 12 msec 40 msec 12 msec
3 222.200.1.2 [AS 222] 24 msec 28 msec 12 msec
6 X.128.0.1 [AS X] 64 msec 64 msec 28 msec
 Os pacotes seguiram o seguinte caminho: AS 222 depois

AS 200 e finalmente AS X.
117
 Veja como os pacotes vão e vem...
AS123
AS55
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 118
 Verifique agora que o mesmo critério (menor AS Path) fez o

router decidir pelo "mesmo caminho” para alcançar o
notebook do aluno:
AS-123-R1>sh ip bgp X.128.0.1

BGP routing table entry for X.0.0.0/8, version 45
Advertised to non peer-group peers:
123.55.2.2
55 111 100 X
123.55.2.2 from 123.55.2.2 (55.55.55.2)
222 200 X
123.222.2.2 from 123.222.2.2 (222.222.222.2)
119
2.4
PERGUNTAS?
120
2.5
Fail-Over
Automático
121
2.5 Fail-Over automático
 Utilizando a rota alternativa

AS-100 AS-200
.1 .1
100.X.1.0/30 . 0/30
0. X .1
E1/0 .2 .2 20
 Vamos simular um problema E2/0
técnico no AS200 deligando AS-X-R1

seus CPE's... F0/0 .254
X.128.0.0/9
GX-R1# terminal monitor

5d06h: %BGP-5-ADJCHANGE: neighbor 200.X.1.1 Down ...
aguardem alguns instantes...

LAB 1-2-2 122
 Agora execute novamente um traceroute a partir do seu laptop:

1 X.128.0.254 3.118 ms 3.492 ms 3.482 ms
2 100.X.1.1 11.808 ms 11.799 ms 17.716 ms
3 111.100.10.1 38.422 ms 108.815 ms 108.392 ms
4 111.111.1.1 133.799 ms 69.868 ms 133.367 ms
5 55.111.2.1 110.819 ms 107.647 ms 65.948 ms
6 55.55.1.1 138.345 ms 129.942 ms 129.917 ms
7 123.55.2.1 115.805 ms * *
ALUNO@notebook:~$
 Com o AS 200 down ,os pacotes entram no AS 100, depois no AS

111, e só depois de passar no AS 55 alcançam o destino (looking
glass).
LAB 1-2-2 123

AS123
AS55
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 124
 Agora note que a rota alternativa (mais distante) passou a ser

utilizada e o "melhor caminho" que havia não existe mais, restando
apenas o "pior caminho" que dadas as circunstâncias, passou a ser
um "ótimo" caminho:
GX-R1>sh ip bgp 123.123.123.1
100 111 55 123
100.X.1.1 from 100.X.1.1 (100.0.0.100)
LAB 1-2-2 125

 Vamos verificar no ponto de vista do Looking Glass:

Trying 123.123.123.1...
Connected to 123.123.123.1.
Password: 123

1 123.55.2.2 8 msec 8 msec 4 msec

2 55.55.1.2 [AS 55] 12 msec 24 msec 16 msec
3 55.111.2.2 [AS 55] 32 msec 28 msec 40 msec
4 111.111.1.2 [AS 111] 52 msec 36 msec 64 msec
5 111.100.1.2 [AS 111] 56 msec 48 msec 52 msec
7 X.128.0.1 [AS 1] 92 msec 68 msec 96 msec
LAB 1-2-2 126

AS123
AS55
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 127
 Verifiquem que o looking glass escolhe o caminho mais

“longo” para chegar ao notebook do aluno:
*agora é a única rota disponível
AS-123-R1>sh ip bgp X.128.0.1
Paths: (1 available, best #1, table Default-IP-Routing-
Table)
123.222.2.2
55 111 100 X
123.55.2.2 from 123.55.2.2 (55.55.55.2)
 E essa mensagem "advertised to... 123.222.2.2" ? Origin IGP, localpref 100, valid, external, best
Nos slides anteriores era "advertised to 123.55.2.2"

 Vamos ver o debug do as 123 após um “clear ip bgp”
 Mas deixa claro que a(s) rede(s) do(s) aluno(s) estão sendo anunciadas para o as 222, e consequentemente
para o AS 200
 Vamos comprovar...
LAB 1-2-2 128

AS123
AS55
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 129
 Partindo do laptop vamos tentar alcançar o AS 200...

1 X.128.0.254 6.128 ms 6.510 ms 6.501 ms
2 100.X.1.1 19.342 ms 19.735 ms 68.139 ms
3 111.100.10.1 68.506 ms 79.031 ms 100.321 ms
4 111.111.1.1 78.604 ms 68.467 ms 68.456 ms
5 55.111.2.1 45.810 ms 39.272 ms 127.491 ms
6 55.55.1.1 136.322 ms 123.845 ms 114.650 ms
7 123.55.2.1 113.618 ms 123.932 ms 112.493 ms
8 123.222.2.2 161.647 ms 101.636 ms 111.676 ms
9 222.222.1.2 161.596 ms 176.097 ms 183.647 ms
10 222.200.1.2 154.398 ms 122.534 ms 101.285 ms
 Agora alcançamos o AS 200 pelo caminho mais longo possível, AS

100, AS 111, AS 55, AS 123, AS 222 e finalmente AS 200.
 Vamos analisar...
LAB 1-2-2 130
 Verifiquem as entradas para a rede em que faz parte o IP do AS-

200-BKB:
GX-R1>sh ip bgp 200.200.200.10

100 111 55 123 222 200
100.X.1.1 from 100.X.1.1 (100.100.100.1)
Origin incomplete, localpref 100, valid, external, best
 Observe o AS Path, precisamos dar a "volta ao mundo" para

alcançar o AS 200.
 Discutiremos soluções alternativas nos próximos capítulos.
LAB 1-2-2 131
 A mesma coisa pode ser observada a partir do R10 do AS 200

Trying 200.200.200.10
Connected to 200.200.200.10
AS-200-BKB>sh ip bgp X.0.0.0

Advertised to peer-groups:
IBGP
222 123 55 111 100 X
222.200.10.1 from 222.200.10.1 (222.222.222.1)
 O novo caminho fica bem mais “longo”, mas não fica fora
LAB 1-2-2 132

Conclusões:
 O protocolo BGP trata praticamente sozinho os problemas de

queda nos links.
 Porém não tem como entender certas variáveis que fazem o link A
ser mais viável que o link B, ou mesmo quando precisamos somar
2 links.
 Em outras palavras, se tenho contratados 100Mbs de trânsito com

o AS 100 e apenas 50 com o AS 200, seria inviável ter o link do AS
200 como principal, e nesse caso precisamos "interferir" na
decisão do protocolo BGP manipulando certos atributos.
133
2.5
PERGUNTAS?
134
2.6
Escolhendo o
Melhor Link
135
 A falha no AS 200 será reestabelecida...
AS123
AS55
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 136
 E o tráfego volta à direção de antes...
AS123
AS55
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 137
AS123
AS55
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 138
2.6 Escolhendo o melhor link
 Considere quase toda a minha demanda de trânsito vindo sempre

do AS 123 as seguintes situações:
 O link entre o AS 222 e 200 está passando por dificuldades.
 A negociação com o AS 100 me garantiu um preço que me

permitiu dobrar a banda contratada.
 Algum outro motivo que me obrigue a utilizar o AS 100 como link

principal e o as 200 como backup.
 Como vimos anteriormente, o BGP escolhe por padrão o as 200,
vamos modificar essa escolha...
139
 Alterando o atributo Weight:
GX-R1#configure terminal
GX-R1(config)#router bgp X
GX-R1(config-router)#neighbor 100.X.1.1 weight 10
GX-R1(config-router)#end
!--- agora vamos efetuar um clear na sessão BGP
GX-R1#clear ip bgp 100.X.1.1
 Vamos verificar como ficaram as rotas BGP...
LAB 1-3-1 140

 Analisando a rota para rede do looking glass após a mudança no

atributo:
GX-R1#sh ip bgp 123.123.123.1
200 222 123

200.X.1.1 from 200.1.1.1 (200.200.200.1)
100 111 55 123

100.X.1.1 from 100.X.1.1 (100.100.100.1)
Origin IGP, localpref 100, weight 10, valid, external, best
 Acabamos de forçar o router a escolher a rota #2, já que o

primeiro critério é o atributo weight, a rota 2# foi escolhida como
melhor mesmo com um as path MAIOR.
LAB 1-3-1 141
 Testando...
 Executem um traceroute do seu laptop para 123.123.123.1

…
...
 Caso a mudança no weight tenha sido bem sucedida os pacotes

seguiram a rota pelo AS 100 ao invés do AS 200.
 Porém isso resolve apenas "metade" do meu problema

conforme veremos no slide seguinte...
LAB 1-3-1 142

 Ping extendido:
GX-R1#ping
Protocol [ip]:
Target IP address: 123.123.123.1
Repeat count [5]: 2
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: X.128.0.254
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: record
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Packet sent with a source address of 172.16.32.1
Packet has IP options: Total option bytes= 39, padded length=40
Record route: <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
LAB 1-3-1 (...continua...)

143
 Ping extendido:
(...continuação...)
(0.0.0.0)
Reply to request 0 (152 ms). Received packet has options

Total option bytes= 40, padded length=40
Record route:
(100.X.1.2)
(111.100.1.2)
(111.111.2.2)
(55.111.1.2)
(55.55.2.2)
(123.55.1.2)
(123.123.123.1)
(123.222.1.1) *essa é interface pelo qual o ping foi respondido
<*>
End of list
<Omited>

GX-R1#
LAB 1-3-1 144

 Agora verificar o ponto de vista do looking glass testando a partir

dele:
ALUNO@notebook:~ telnet 123.123.123.1
!--- Efetuem um traceroute para o seu laptop

1 123.222.1.2 32 msec 16 msec 16 msec

2 222.222.1.2 [AS 222] 16 msec 36 msec 36 msec
3 222.200.1.2 [AS 222] 68 msec 48 msec 44 msec
AS-123-R1>
LAB 1-3-1 145

 Como podemos verificar, o AS 123 continua escolhendo a mesma

rota, uma vez que a mudança no atributo weight, teve influência
apenas no meu UPLOAD, sendo assim, meu download continua
chegando pelo AS 200 (menor AS PATH no ponto de vista do AS
123).
 Não tenho como pedir que o AS 123 altere os seus atributos,
preciso convencê-los de outra forma a mudar de rota.
LAB 1-3-1 146

AS123
AS55
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 147
 Fazendo anúncios mais específicos para o AS 100
 Como mencionado anteriormente, os atributos BGP só são

analisados quando há um empate de prefixo, porém quando há um
prefixo MAIS ESPECÍFICO os atributos são ignorados.
 Quais blocos anunciar para cada AS?
 Dividiremos em 2 blocos /9 para o as 100 e o /8 para o AS 200.
LAB 1-3-1 148

AS123
AS55
X.0.0.0/8
X.0.0.0/9
X.128.0.0/9 AS222
AS111
AS100 AS200
X.0.0.0/9 X.0.0.0/8
X.128.0.0/9
ASX
LAB 1-2-1 149
 Configurando os anúncios mais específicos:

AS-X-R1#conf terminal
AS-X-R1(config)#ip prefix-list LAB-1-3-1-ANUNCIAR-AS-100 permit X.0.0.0/9
!--- adiciona 2 prefixos /9 dentro da lista ”ANUNCIAR-AS-100”
!--- adiciona o classe A inteiro dentro da lista ”ANUNCIAR-AS-100”
!--- além do anuncio local do classe A, inserimos mais 2 prefixos /9 a serem
!--- a serem anunciados pelo router
AS-X-R1(config-router)#neighbor 200.X.1.1 prefix-list LAB-1-3-1-ANUNCIAR-AS-200 out
!--- declara que esse anuncios de saida (out) para esse neighbor serao filtrados
LAB 1-3-1 150

 Verificando anúncios para o AS 200:


*> X.0.0.0 0.0.0.0 0 32768 i
 Agora para o AS 100:

(...)
*> X.128.0.0/9 0.0.0.0 0 32768 i
 Estamos anunciando apenas um dos blocos /9 para o AS 100, por
que?
LAB 1-3-1 151

 Apenas um prefixo pertencente ao meu classe A está na FIB:
AS-X-R1#sh ip route X.0.0.0 longer-prefixes

...
Gateway of last resort is not set
X.0.0.0/8 is variably subnetted, 4 subnets, 3 masks

C X.0.0.1/32 is directly connected, Loopback0
C X.X.1.0/30 is directly connected, GigabitEthernet3/0
C X.101.1.0/30 is directly connected, GigabitEthernet5/0
C X.128.0.0/9 is directly connected, FastEthernet0/0
 O comando ”longer-prefixes” mostra rotas para qualquer sub-rede

dentro do bloco /8 pesquisado, porém temos um /32 na Loopback0,
o segundo /9 diretamente conectado à f0/0, outros 2 /30, mas em
nenhum lugar aparece X.0.0.0/9
LAB 1-3-1 152

 Precisamos primeiramente garantir que as redes que quero
anunciar estejam em minha FIB:
AS-X-R1#conf t
AS-X-R1(config)#ip route X.0.0.0 255.0.0.0 null0
AS-X-R1(config)#ip route X.0.0.0 255.128.0.0 null0
AS-X-R1(config-router)#no auto-summary
AS-X-R1(config)#end
AS-X-R1
AS-X-R1#sh ip route X.0.0.0 longer-prefixes
...
Gateway of last resort is not set
1.0.0.0/8 is variably subnetted, 6 subnets, 4 masks
C X.0.0.1/32 is directly connected, Loopback0
C X.X.1.0/30 is directly connected, GigabitEthernet3/0
S X.0.0.0/9 is directly connected, Null0
S X.0.0.0/8 is directly connected, Null0
C X.101.1.0/30 is directly connected, GigabitEthernet5/0
C X.128.0.0/9 is directly connected, FastEthernet0/0
 Agora que tenho os 2 blocos /9 em minha FIB vamos verificar
novamente os anúncios para o AS 100...
LAB 1-3-1 153

 Agora que tenho os 2 blocos /9 em minha FIB vamos verificar

novamente os anúncios para o AS 100...


*> X.0.0.0/9 0.0.0.0 0 32768 i
*> X.128.0.0/9 0.0.0.0 0 32768 i
 Agora estamos fazendo corretamente o anúncio dos dois blocos /9

para o AS 100.
LAB 1-3-1 154

 Vamos novamente entrar no looking glass e verificar as rotas para

classe A do grupo:
AS-123-R1>sh ip bgp X.0.0.0/8 longer-prefixes


*> X.0.0.0/9 123.55.2.2 0 55 111 100 X i
*> X.0.0.0 123.222.2.2 0 222 200 X i
*> X.128.0.0/9 123.55.2.2 0 55 111 100 X i
Dessa forma, a rota em vermelho nunca é usada, pois existem dois

blocos mais específicos, fazendo com que o LG sempre alcance os
AS's dos grupos através do AS 100.
LAB 1-3-1 155

 Verificando caminho percorrido com o comando traceroute:

1 123.55.2.2 20 msec 24 msec 12 msec

2 55.55.1.2 [AS 55] 32 msec 32 msec 44 msec
3 55.111.2.2 [AS 55] 20 msec 36 msec 32 msec
4 111.111.1.2 [AS 111] 40 msec 56 msec 36 msec
5 111.100.10.2 [AS 111] 88 msec 28 msec 56 msec
7 X.128.0.2 [AS X] 60 msec 60 msec 80 msec
AS-123-R1>
 No início forçamos o upload pelo AS 100, e agora também o

download pelo AS 100.
LAB 1-3-1 156
 Agora IDA e VOLTA seguem a mesma rota
AS123
AS55
AS222
AS111
AS100 AS200
ASX
LAB 1-2-1 157
2.6
PERGUNTAS?
158
2.7
Balanceando os
Links
159
2.7-Balanceando os links
 Antes de começar é preciso remover a configuração de “weight”

aplicada no LAB anterior
AS-X-R1(config-router)#no neighbor 100.X.1.1 weight 10
!--- agora vamos efetuar um clear na sessão BGP
AS-X-R1#clear ip bgp 100.X.1.1
 Vamos verificar como ficaram as rotas BGP...

LAB 1-3-1 160
 Vamos agora considerar uma situação de necessidade de

utilizar os dois links de maneira balanceada.
 Dividiremos cada metade do /8 para cada AS.
 Anunciaremos o primeiro /9 para o AS 100 e o segundo /9

para o AS 200 fazendo com que o nosso tráfego inbound
seja divido em 50% para cada link.
 A lógica é a mesma, o que faremos diferente do lab anterior

é um detalhe para o fail-over.
161
 Vamos criar duas novas prefix-lists e adiciona-las como filtro
de SAÍDA para cada AS de trânsito:
AS-X-R1#conf terminal
!--- adiciona o classe A inteiro dentro da lista ”ANUNCIAR-AS-100”
LAB 1-4-1 162

 Vamos criar duas novas prefix-lists e adiciona-las como filtro
de SAÍDA para cada AS de trânsito:
AS-X-R1#show ip bgp neighbors 100.X.1.1 advertised-routes

(...)
*> X.0.0.0/9 0.0.0.0 0 32768 i
*> X.0.0.0 0.0.0.0 0 32768 i
Total number of prefixes 2

(...)
*> X.0.0.0 0.0.0.0 0 32768 i
*> X.128.0.0/9 0.0.0.0 0 32768 i
LAB 1-4-1 163

 Anunciando um /9 para cada lado
AS123
AS55
X.0.0.0/8
X.0.0.0/8 AS222
X.0.0.0/9
AS111 X.128.0.0/9
AS100 AS200
X.0.0.0/9 X.128.0.0/9
X.0.0.0/8 ASX X.0.0.0/8
LAB 1-2-1 164
 Vamos entrar no looking glass e ver o resultado:
AS-123-R1>sh ip bgp X.0.0.0/8 longer-prefixes

...
*> X.0.0.0/9 123.55.1.2 0 55 111 100 X i
* X.0.0.0 123.55.1.2 0 55 111 100 X i
*> 123.222.1.2 0 222 200 X i
*> X.128.0.0/9 123.222.1.2 0 222 200 X i
 Agora testar o caminho para os 2 blocos /9.
LAB 1-4-1 165

 Primeiro /9 (Loopback do router):


1 123.55.2.2 8 msec 16 msec 16 msec

2 55.55.1.2 [AS 55] 44 msec 12 msec 16 msec
3 55.111.2.2 [AS 55] 24 msec 32 msec 32 msec
4 111.111.1.2 [AS 111] 48 msec 28 msec 48 msec
5 111.100.10.2 [AS 111] 48 msec 48 msec 56 msec
6 100.100.1.2 [AS 100] 60 msec 88 msec 112 msec
AS-123-R1>
 Caminho 55,111,100
LAB 1-4-1 166

 O tráfego com destino ao IP's dentro de X.0.0.0/9 seguem pela

rota 55, 111, 100...
AS123
AS55
X.0.0.0/8
X.0.0.0/8 AS222
X.0.0.0/9
AS111 X.128.0.0/9
AS100 AS200
X.0.0.0/9 X.128.0.0/9
X.0.0.0/8 ASX X.0.0.0/8
LAB 1-2-1 167
 Segundo /9 (ip do laptop):

AS-123-R1#traceroute X.128.0.1

1 123.222.2.2 24 msec 4 msec 32 msec

2 222.222.1.2 [AS 222] 40 msec 8 msec 16 msec
3 222.200.10.2 [AS 222] 32 msec 24 msec 16 msec
AS-123-R1#
 Caminho 222,200
LAB 1-4-1 168

 O tráfego com destino ao IP's dentro de X.128.0.0/9 seguem pela

rota 222, 200...
AS123
AS55
X.0.0.0/8
X.0.0.0/8 AS222
X.0.0.0/9
AS111 X.128.0.0/9
AS100 AS200
X.0.0.0/9 X.128.0.0/9
X.0.0.0/8 ASX X.0.0.0/8
LAB 1-2-1 169
 Simulação de problemas nos CE's do AS 100...

 Todos verificam a mudança!
 Simulação de problemas nos CPE's do AS 200...

 Todos verificam a mudança!
LAB 1-4-2 170

 Em uma eventual falha no AS 200 a rede X.128.0.0/9

desaparece...
AS123
AS55
X.0.0.0/8
X.0.0.0/8 AS222
X.0.0.0/9
AS111 X.128.0.0/9
AS100 AS200
X.0.0.0/9 X.128.0.0/9
X.0.0.0/8 ASX X.0.0.0/8
LAB 1-2-1 171
 Em uma eventual falha no AS 200 a rede X.128.0.0/9

desaparece...
AS123
AS55
X.0.0.0/8
X.0.0.0/8 AS222
X.0.0.0/9
AS111 X.128.0.0/9
AS100 AS200
X.0.0.0/9 X.128.0.0/9
X.0.0.0/8 ASX X.0.0.0/8
LAB 1-2-1 172
 Apesar da rota desaparecer, todos os IP's dentro de X.128.0.0/9

seguirão a rota X.0.0.0/8 já que essa rota contem X.128.0.0/9
AS123
AS55
X.0.0.0/8
X.0.0.0/8 AS222
X.0.0.0/9
AS111 X.128.0.0/9
AS100 AS200
X.0.0.0/9 X.128.0.0/9
X.0.0.0/8 ASX X.0.0.0/8
LAB 1-2-1 173
 OBS: Para um balanceamento assimétrico mudaríamos os

anúncios, quebrando para blocos cada vez mais específicos
 Nunca esquecer de que o balanceamento baseado em

anúncios específicos depende da distribuição dos IPs dentro
do meu AS.
LAB 1-4-2 174

3.0
Peering e Troca de
Tráfego
3. Peering e Troca de tráfego
• 3.1 Peering x Trânsito

• 3.2 Entendendo o funcionamento de um PIX
• 3.3 Formulários de adesão
• 3.4 Diferenças entre acordo bilateral e multilateral
• 3.5 Participantes locais e remotos
• 3.6 Entendendo o conceito de Lan2Lan
• 3.7 ATM-Tratando as rotas recebidas
• 3.8 ATM-Anunciando corretamente
• 3.9 O looking glass do PTT Metro
• 3.10 Aplicações de um acordo bilateral
• 3.11 Comprando e vendendo trânsito no PTT
175
3.1
Peering x Trânsito
176
3.1 Peering x Trânsito
 Em primeiro lugar devem ser separados os conceitos de

peering e trânsito.
 Quando dois AS's tem uma quantidade de demanda comum,

acaba saindo mais barato o peering.
 Exemplo, eu sou AS A, e tenho uma demanda de 10Mbs de

download de um certo conteúdo hospedado no AS B.
 Para resolver isso, contrato um link de 10Mbs da operadora B e

pago R$ 100,00 por cada mega, num total de R$ 1.000,00.
177
 Porem, a operadora B também tem uma demanda de 10Mbs

de conteúdo hospedado no meu AS A.
 Isso dá para operadora B uma conta semelhante de R$

1.000,00 mensais.
 No final do mês, ficaríamos empatados no custo, e o melhor a

se fazer é estabelecer um link direto de 10Mbs sem que um
cobre do outro.
 Há outras vantagens técnicas como menor caminho BGP e

menor latência.
178
 LAB: Observem o cenário...
179
 LAB: Estabelecer peering entre grupos com os seguintes Ips:
AS IP AS IP
1 1.2.1.1/30 x 2 1.2.1.2/30
3 3.4.1.1/30 x 4 3.4.1.2/30
5 5.6.1.1/30 x 6 5.6.1.2/30
7 7.8.1.1/30 x 8 7.8.1.2/30
9 9.10.1.1/30 x 10 9.10.1.2/30
11 11.12.1.1/30 x 12 11.12.1.2/30
13 13.14.1.1/30 x 14 13.14.1.2/30
LAB 1-6-1 180

 LAB: Estabelecer peering entre grupos com os seguintes Ips:
AS-100
AS-200
.1
.1
100.X.1.0/30 / 3 0
1.0 AS IP AS IP
.2 E2/0 0 .X.
E1/0 20 1 1.2.1.1/30 x 2 1.2.1.2/30
.2
AS-X-R1 PEERING 3 3.4.1.1/30 x 4 3.4.1.2/30
F0/0 IP.DO.PEERING
5 5.6.1.1/30 x 6 5.6.1.2/30
.254
7 7.8.1.1/30 x 8 7.8.1.2/30
X.128.0.0/9 9 9.10.1.1/30 x 10 9.10.1.2/30
11 11.12.1.1/30 x 12 11.12.1.2/30
.1 13 13.14.1.1/30 x 14 13.14.1.2/30
LAB 1-6-1 181

 Realizando as configurações IP (AS ÍMPAR):
AS-XR1#conf t
AS-X-R1(config)#interface g4/0
AS-X-R1(config-if)#ip address X.Y.1.1 255.255.255.252
AS-X-R1(config-if)#no shutdown
AS-X-R1(config-if)#end
AS-X-R1#ping X.Y.1.2

.!!!!
Onde:
X= AS local
Y= AS remoto
LAB 1-6-1 182

 Realizando as configurações IP (AS PAR):
AS-XR1#conf t
AS-X-R1(config-if)#ip address Y.X.1.2 255.255.255.252
AS-X-R1#ping Y.X.1.1

.!!!!
Onde:
X= AS local
Y= AS remoto
LAB 1-6-1 183

 Antes de começar vamos desfazer algumas das

configurações dos laboratórios anteriores...
AS-X-R1#conf t
AS-X-R1(config)#no router bgp X
AS-X-R1(config)#no ip route X.0.0.0 255.0.0.0 Null0
AS-X-R1(config)#no ip route X.0.0.0 255.128.0.0 Null0
 O Objetivo é parar de propagar prefixos /9 e voltar à

anunciar apenas /8 para os trânsitos a agora para o
peering
LAB 1-6-1 184

 Configurando BGP (AS ÍMPAR): Onde:

AS-X-R1(config)#router bgp X X= AS local
AS-X-R1(config-router)#network X.0.0.0 Y= AS remoto
AS-X-R1(config-router)#auto-summary
AS-X-R1(config-router)#neighbor 100.X.1.1 remote-as 100
*Jan 21 00:06:34.958: %BGP-5-ADJCHANGE: neighbor 100.X.1.1 Up
*Jan 21 00:07:08.046: %BGP-5-ADJCHANGE: neighbor 200.x.1.1 Up
AS-X-R1(config-router)#neighbor X.Y.1.2 remote-as Y
*Jan 21 00:09:06.434: %BGP-5-ADJCHANGE: neighbor X.Y.1.2 Up
AS-X-R1(config-router)#neighbor X.Y.1.2 weight 20
!--- priorizar todas as rotas recebidas pelo peering com weight 20
AS-X-R1(config-router)#neighbor X.Y.1.2 prefix-list MEUS-BLOCOS out
!--- filtrar anúncios de saída para esse peering na respectiva prefix-list
LAB 1-6-1 185
 Configurando BGP (AS PAR): Onde:

AS-X-R1(config)#router bgp X X= AS local
AS-X-R1(config-router)#network X.0.0.0 Y= AS remoto
AS-X-R1(config-router)#neighbor Y.X.1.1 remote-as Y
*Jan 21 00:09:06.434: %BGP-5-ADJCHANGE: neighbor Y.X.1.1 Up
AS-X-R1(config-router)#neighbor Y.X.1.1 weight 20
!--- priorizar todas as rotas recebidas pelo peering com weight 20
AS-X-R1(config-router)#neighbor Y.X.1.1 prefix-list MEUS-BLOCOS out
!--- filtrar anúncios de saída para esse peering na respectiva prefix-list
LAB 1-6-1 186
 Verificando os anúncios para o novo peering:
AS-X-R1#sh ip bgp neighbors X.X.X.X advertised-routes

...
*> X.0.0.0 0.0.0.0 0 32768 i
!-- x.x.x.x é o endereço remoto do seu peering
 O Next Hop 0.0.0.0 e o weight 32768 indicam que as redes foram

originadas localmente ou seja, no comando:
router(config-router) network x.x.x.x mask x.x.x.x
LAB 1-6-1 187

 Verificando as redes recebidas do meu novo peering:
AS-X-R1#sh ip bgp neighbor X.X.X.X routes

!--- verificando as rotas recebidas pelo peering
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,

*> Y.0.0.0 1.2.1.2 0 20 Y i
Total number of prefixes 1 Onde:

X= AS local
Y= AS remoto
LAB 1-6-1 188

 Testando um traceroute para Y.128.0.1 ...

ALUNO@notebook# traceroute Y.128.0.1 -n
traceroute to 2.0.0.1 (2.0.0.1), 30 hops max, 60 byte
packets
1 X.128.0.254 5.911 ms 15.863 ms 25.922 ms
2 X.X.X.X 46.113 ms 39.461 ms 66.244 ms
3 Y.128.0.254 151.540 ms 99.734 ms 108.429 ms
 A partir de agora está havendo uma troca de tráfego entre
os 2 AS's.
LAB 1-6-1 189

 O que faz dessa configuração um peering e não um

trânsito?
 Ao caírem os links do AS200 e AS100 apenas as redes do

peering continuariam funcionando, e isso é o que
descaracteriza um trânsito.
LAB 1-6-1 190

 Vamos simular uma falha nos AS's de trânsito e verificar a
conectividade entre os 2 AS's que fazem peering...
X
AS-100
.1
X
AS-200
.1
100.X.1.0/30
. 0/ 30
X. 1
.
E1/0 .2 E2/0
200
.2
AS-X-R1 PEERING
F0/0 IP.DO.PEERING
.254
X.128.0.0/9
.1
LAB 1-6-1 191

3.2
Entendendo o
Funcionamento
de Um PIX do PTTMetro
192
3.2 Entendendo o Funcionamento de um
PIX do PTTMetro
 Para quem ainda não assistiu:
http://zappiens.br:80/videos/cgiE9WjKruzQGmPy-VDyEDDAK
PUNxmfYneBOql0VJJOuIg.FLV
193
3.2 Entendendo o Funcionamento de
um PIX do PTTMetro
 Entendendo a necessidade de peerings entre centenas de ASs

do Brasil, o NIC.br organizou diversos pontos de troca.
 Seu funcionamento consiste basicamente em 1 switch, 2 route-

servers e um router Looking Glass (outros maiores como SP
possuem dezenas de switchs em vários PIXes).
194
um PIX do PTTMetro
 Todos os participantes compartilham um mesmo bloco /24

ou /21 (no caso do PTT-SP), cada participante tem um IP, e
todos pingam entre si.
 Estabelecem conexões BGP com os route-servers e o looking

glass.
195
um PIX do PTTMetro
 Os Route Servers cumprem um papel fundamental
dispensando a necessidade de que todos os participantes
façam peering individualmente.
 Imaginem centenas de participantes estabelecendo peering
(todos com todos).
187.16.216.0/22
ROUTE
SERVER
.1
.2
.3
.4
196
3.3
Formulários de Adesão
197
3.3 - Formulários de Adesão
 Para se conectar do PTT-SP por exemplo, acesse o endereço:
http://sp.ptt.br/adesao.html
198
3.3 - Formulários de Adesão
 Para facilitar há um formulário modelo já preenchido:

...
Termo de conexão ao PTTMetro
...
Localidade ........: (Coloque aqui a localidade do PTT que deseja se conectar) Listagem: http://ptt.br/adesao.php
ASN ...............: 22548
Entidade Nome .....: Registro.br
URL ...............: http://registro.br/
Endereço ..........: Av. das Nações Unidas 11548, 7° andar 04578-000 - São Paulo - SP
NOC email .........: noc@registro.br
INOC-DBA ext ......: 22548*NOC
Telefone ..........: 11 5509-3510
Adm-c nome ........: Frederico A C Neves
email .............: fneves@registro.br
Telefone ..........: 11 5509-3511
Peering-c nome ....: Oripide Ocilento Filho
email .............: oripide@nic.br
Telefone ..........: 11 5509-3520
Comercial Trânsito :
email .............:
Telefone ..........:
URL Política
Peering .......: none - Open Policy
BGP Feed para o
Looking-glass ...: Sim [x] Nao [ ]
Vende trânsitov4 ..: Sim [ ] Não [x]
Vende trânsitov6 ..: Sim [ ] Não [x]
Conexão
Bandwidth .........:
Media Ethernet ....: 10BaseTX [ ] 100BaseTX [ ] 10000BaseTX [ ]
1 GigE-SX [X] 1 GigE-LX [ ] 10 GigE-SR [ ] 10 GigE-LR [ ]
PIX ...............: Registro.br
IPv6 ..............: Sim [x] Nao [ ]
...
199
3.4
Diferenças entre Acordo
Bilateral
e Multilateral
200
3.4 - Diferenças entre Acordos
Bilaterais e Multilaterais
 Estar no PTT por si só não significa trocar tráfego!
 Existem participantes que optaram em não trocar tráfego
multilateral (todos com todos).
 E esse é um direito do participante...
201
 Acordo de troca Multilateral (ATM)
 Para trocar tráfego com todos os participantes, além do termo

de conexão ao PTTmetro, é preciso preencher o termo de
adesão ao ATM (Acordo de Troca Multilateral).
 No acordo multilateral o participante recebe uma vlan+ip e
troca tráfego com todos.
...
Termo de adesão ao Acordo de Troca de Tráfego Multilateral (ATM)
Version .........: 2008071000
Este termo de adesão trata das informações e compromissos da entidade
solicitante para a participação no acordo de troca de tráfego
multilateral no PTTMetro.
Localidade ......: sp.ptt.br
ASN .............: 22548
Entidade Nome ...: Registro.br
ATM v4 ..........: Sim [x] Não [ ]
ATM v6 ..........: Sim [x] Não [ ]
...
 Após preenchidos ambos devem ser encaminhados para join@ptt.br

202
 Acordo de troca Bilateral
 No acordo bilateral, 2 participantes manifestam interesse e
recebem uma vlan comum, que fica extendida às duas
extremidades e, por se tratar de um serviço em layer 2, os
IPs ficam à critério desses 2 participantes.
 Em outras palavras, o PTTmetro providencia toda estrutura de
um ”peering” para ambos.
 Os AS's que se conectam ao

PTT mas não participam do
ATM, em geral vendem trânsito através de
acordos bilaterais
203
3.5
Participantes Locais e
Remotos
204
3.5 - Participantes Locais e Remotos
 Para participar é preciso ter conectividade layer2 com o switch

do PTT-Metro. Para isso há duas formas:
#1- Conectando-se fisicamente em um dos switches de um
dos PIXs atraves de cabo/fibra:
205
3.5 - Participantes Locais e Remotos
 Ou...
2# - Contratando transporte layer2 (lan2lan, clear channel)
de algum participante conectado fisicamente.
 Não há diferenças no ponto de vista técnico entre as duas
modalidades, exceto pelas consequẽncias do aumento de
latência, que é proporcional à distância geográfica.
206
3.6
Entendendo o Conceito de
Lan2Lan
207
3.6 Entendendo o Conceito de Lan2Lan
 Para participar remotamente de um PTT, é necessário que o

participante troque informações de nível de enlace, ou seja,
além de um IP diretamente conectado, o MAC original deve
ser conhecido pelos participantes através de solicitações
ARP
 Em outras palavras, o participante remoto deve fazer parte do

mesmo “domínio de broadcast” que os route servers e
demais participantes
208
3.6 Entendendo o Conceito de Lan2Lan
 Um Tunel layer 2 ou “Lan2Lan” na prática não se parece muito

com um “tunel”, ele pega o QUADRO ETHERNET original e
encapsula no campo de dados do pacote IP
 O router destinatário desencapsula, reproduz o QUADRO

ETHERNET ORIGINAL e joga na inteface correspondente.
 Dessa maneira, todas as informações de “layer 2” chegam ao

outro lado, incluindo requisições ARP e broadcasts
209
3.7
ATM-Tratando as Rotas
Recebidas
210
3.7 - ATM-Tratando as Rotas Recebidas
 LAB: Estabelecer sessões BGP com o PTT Route-server e com o
PTT Looking Glass:
AS-X-R1#conf t
AS-X-R1(config-router)#no bgp enforce-first-as
AS-X-R1(config-router)#neighbor 187.16.216.253 remote-as 555
AS-X-R1(config-router)#neighbor 187.16.216.253 description PTT-SP Route_Server 1
AS-X-R1(config-router)#neighbor 187.16.216.253 weight 15
!--- o valor 15 de weight deve ser menor que o aplicado no peering "20”
AS-X-R1(config-router)#neighbor 187.16.216.253 prefix-list MEUS-BLOCOS out
!--- vamos anunciar apenas o bloco /8 para o PTT e todos os outros neighbors
AS-X-R1(config-router)#neighbor 187.16.216.254 description PTT-SP Route_Server 2
AS-X-R1(config-router)#neighbor 187.16.216.254 weight 15
AS-X-R1(config-router)#neighbor 187.16.216.254 prefix-list MEUS-BLOCOS out
!--- a configuração deve ser idêncita com o route server de backbup
AS-X-R1(config-router)#neighbor 187.16.216.252 description PTT-SP Looking Glass
!--- para o looking glass do PTT enviaremos todas as rotas da FIB, portando nao usaremos
nenhum filtro de out e também nenhum filtro de IN pois o mesmo não anuncia rotas para
ninguém
LAB 1-7-1 211

 LAB: Estabelecer sessões BGP com os PTT Route-server e com
o PTT Looking Glass:
X
AS-100
.1
X
AS-200
 PTT-SP Route Server 1:
100.X.1.0/30 / 30 .1 187.16.216.253
.1 .0
.2 E2/0 0.X PTT-SP Route Server 2:
20

E1/0
.2 187.16.216.254
AS-X-R1 PEERING
F0/1
F0/0  PTT-SP Looking Glass:
.254 .X 187
.16 187.16.216.252
.21
6.0
X.128.0.0/9 / 22 PTT-SP
.1
LAB 1-7-1 212

3.7 - ATM- Tratando as Rotas Recebidas
 Agora vamos verificar se recebemos rotas dos Route Servers
do PTT-SP e se todas as 6 sessões estão estabelecidas:
 Peering
 Trânsito AS100
 Trânsito AS200
 PTT-SP Looking Glass
 PTT-SP Route Server 1
 PTT-SP Route Server 2
AS-X-R1#show ip bgp summary
(...)
X.X.X.X 4 Y 116 124 17 0 0 01:18:00 1
100.X.1.1 4 100 146 114 17 0 0 01:19:56 27
187.16.216.252 4 555 14 22 17 0 0 00:11:37 0
187.16.216.253 4 555 37 46 17 0 0 00:34:39 13
187.16.216.254 4 555 41 53 17 0 0 00:18:04 13
200.X.1.1 4 200 147 122 17 0 0 01:19:56 26
LAB 1-7-1 213
 Vamos verificar todas as opções para chegar à rede do AS do
colega de peering
AS-X-R1>show ip bgp Y.0.0.0/8
BGP routing table entry for Y.0.0.0/8, version 17
1
Y
187.16.216.2 from 187.16.216.253 (187.16.216.253)
Origin IGP, metric 0, localpref 100, weight 15, valid, external
Y
187.16.216.2 from 187.16.216.254 (187.16.216.254)
200 Y
200.X.1.1 from 200.1.1.1 (200.0.0.100)
100 Y
100.X.1.1 from 100.1.1.1 (100.0.0.100)
Y
X.X.X.X from X.X.X.X (Y.0.0.1)
Origin IGP, metric 0, localpref 100, weight 20, valid, external, best
 A rota escolhida é a #5 porque o valor de weight do peering (20)

é maior do que o valor aplicado às rotas do PTT-SP (15)
LAB 1-7-1 214
 Agora vamos verificar as rotas a a conectividade entre os
outros AS's
LAB 1-7-1 215

3.8
ATM-Anunciando
Corretamente
216
3.8- ATM- Anunciando Corretamente
 Utilizamos anúncios da maneira mais simples possível, porém, no mundo
real, o mais recomendado é anunciar blocos mais específicos para os
pontos de troca.
 Um dos principais motivos são os participantes indiretos.
 Digamos que o administrador do AS 44 coloca baixa prioridade para rotas
recebidas pelo AS 30, ou mesmo que o BGP tenha escolhido sozinho o
AS 100 como melhor rota por ser a mais antiga por exemplo
217
3.8- ATM- Anunciando Corretamente
 Os anúncios mais específicos garantem tráfego de download pelo PTT,

porém também existem outras maneiras de fazer isso, utilizando
communities e as path prepend.
218
3.9
O Looking Glass do PTT

Metro
219
3.9 - O Looking Glass do PTT Metro
 O Looking Glass do PTT-Metro foge um pouco do padrão,

quando visualizamos uma rota como ”best” não significa
que essa é a rota que está sendo escolhida pelos
participantes do PTT.
 Ele não envia nenhuma rota, e todos os participantes devem

enviar a sua tabela full.
 Assim, é uma ferramenta para ajudar a visualizar toda a

tabela de roteamento de cada participante.
220
 Conectando-se ao Looking Glass do PTT-SP:
AS-X-R1>telnet 187.16.216.252
Trying 187.16.216.252 ... Open
Ubuntu 14.10
PTT-SP-LG login: lg.ptt.sp
Password: 123456
$
$ telnet 127.0.0.1 bgpd
Trying 127.0.0.1...
Hello, this is Quagga (version 0.99.23).

Copyright 1996-2005 Kunihiro Ishiguro, et al.
Password: 123456
PTT-SP-LG>
 Pronto! Agora estamos conectados ao Looking Glass e
poderemos fazer consultas...
221
 Digamos que quero verificar a tabela de roteamento do
participante do PTT que possui o AS 1.
PTT-SP-LG> show ip bgp regexp ^1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed

*> 1.0.0.0 187.16.216.1 0 01i
*> 2.0.0.0 187.16.216.1 012i
*> 55.0.0.0 187.16.216.1 0 1 100 111 55 i
*> 100.0.0.0 187.16.216.1 0 1 100 i
*> 111.0.0.0 187.16.216.1 0 1 100 111 i
*> 123.0.0.0 187.16.216.1 0 1 200 222 123 i
(..)
 Esse comando mostraria todas as rotas BGP na FIB do AS 1

(desde que esse esteja enviando sua tabela full para esse
Looking Glass).
222
3.10
Aplicações de Um Acordo
Bilateral
223
3.10 Aplicações de Um Acordo Bilateral
 Com um acordo bilateral um AS pode vender trânsito para

outro AS participante dispensando os custos de ativação
(estrutura e equipamentos).
 Outra aplicação interessante é uma parceria entre 2 AS's de

cidades diferentes para interligar um cliente comum em
L2.
224
3.11 Comprando e vendendo trânsito no
PTT
 LAB acordo bilateral:
● Os grupos escolherão com quem fazer o acordo bilateral e

terão uma vlan comum escolhida pelo instrutor.
● O objetivo é semelhante ao LAB do ”peering”, porém, um

dos participantes fornecerá trânsito IP para o outro que
será apenas cliente.
LAB 1-8-1 225

PTT
 Para isso, deve ser estabelecida uma sessão BGP entre os

dois, onde o responsável em prover trânsito deverá
anunciar a tabela full para o cliente ao mesmo tempo que
anuncia os prefixos do cliente para suas duas operadoras:
AS 100 e AS 200.
 Após decidido o ID da vlan, cada participante deve
inserir a tag correspondente na interface f0/1 (interface
conectada ao PTT).
 Os IPs de WAN serão definidos pelos participantes,
 XXX é o número (ID) da vlan e Z.Z.Z.Z o endereço

LAB 1-8-1
IP que o cliente configurou do outro lado
226
PTT
 IP's privadsos podem ser usados para algumas demandas
de segurança, porém pode causar certas complicações
com traceroutes
 Após decidido o ID da vlan cada participante deve inserir a
tag correspondente na interface f0/1 (interface conectada
ao PTT).
 Os IPs de WAN serão definidos pelos participantes,
AS-X-R1#conf t
AS-X-R1(config)#interface fastEthernet 0/1
AS-X-R1(config-subif)#ip address(combinem os endereços IP de cada lado) secondary
AS-X-R1(config-subif)#end
AS-X-R1# ping Z.Z.Z.Z
!--- testem conectividade IP através da vlan antes de iniciar as config BGP
X.X.X.X é o Iocal e Z.Z.Z.Z o IP configurado do lado remoto
o endereço IP que o cliente configurou do outro lado
LAB 1-8-1 227
PTT
 Logo abaixo segue qual seria a maneira de configurar no
cenário real do PTT-SP, com TAG vlan.
Router#conf t
Router(config)#interface fastEthernet 0/1.XXX NÃO APLIQUE ESSA CONFIG!
Router(config-subif)#encapsulation dot1Q XXX NÃO FAZ PARTE DO LAB
Router(config-subif)#ip address z.z.z.z
Router(config-subif)#end
Router# ping Z.Z.Z.Z
 XXX é o número (ID) da vlan e Z.Z.Z.Z o endereço IP

que o cliente configurou do outro lado
LAB 1-8-1 228

PTT
 Configurando VLAN/IP na interface PTT
 Uma boa recomendação para o AS que venderá o trânsito
nesse laboratório é usar um de seus /30 (ou /31) públicos
na “WAN” de quem vai ser cliente um IP , assim os
tracerouters ficarão menos complicados de ler
!--- testem conectividade IP antes de iniciar as config BGP
AS-X-R1#ping Z.Z.Z.Z

!!!!!
 XXX é o número (ID) da vlan e Z.Z.Z.Z o endereço
IP que o cliente configurou do outro lado
LAB 1-8-1 229
PTT
 Configurações BGP no router que será TRÂNSITO:
 OBS: onde houver Y substituiremos pelo AS do CLIENTE, e Z.Z.Z.Z pelo IP que foi combinado
AS-X-R1#conf t previamente com o cliente e configurado do outro lado da VLAN
AS-X-R1(config-router)#neighbor Z.Z.Z.Z remote-as Y
AS-X-R1(config-router)#neighbor Z.Z.Z.Z description Acordo bilateral - cliente
AS-X-R1(config-router)#neighbor Z.Z.Z.Z weight 25
!--- o valor de weight deve ser maior do todos os outros já que se trata de um cliente de trânsito
AS-X-R1(config-router)#neighbor Z.Z.Z.Z prefix-list BLOCOS-CLIENTE-AS-Y in
!--- dessa vez utilizaremos um filtro de entrada ”in” para não haver risco de receber do cliente
!--- prefixos que não sejam dele e meu tráfego de output ir na direção desse cliente
AS-X-R1(config-router)#exit
AS-X-R1(config)#ip prefix-list BLOCOS-CLIENTE-AS-Y permit Y.0.0.0/8
!--- adiciono o classe A do cliente na prefix-list declarada como filtro de entrada
AS-X-R1(config)#ip prefix-list MEUS-BLOCOS permit Y.0.0.0/8
!--- como já utilizamos a prefix-list ”MEUS-BLOCOS” na saída dos AS de trânsito,
!--- vamos ”aproveita-la” e apenas adicionar mais um prefixo
LAB 1-8-1 230
PTT
LAB 1-8-1 231
PTT
LAB 1-8-1 232
PTT
 Configurações BGP no router CLIENTE:
 OBS: onde houver Y substituiremos pelo AS que será TRÂNSITO, e Z.Z.Z.Z pelo IP que está
configurado do outro lado
AS-X-R1#conf t
AS-X-R1(config-router)#neighbor Z.Z.Z.Z description Acordo bilateral-transito IP
AS-X-R1(config-router)#neighbor Z.Z.Z.Z prefix-list MEUS-BLOCOS out
!--- como cliente devemos anunciar da mesma maneira que fizemos com os ASs de trânsito
!--- e já que o classe A local já está nessa lista não preciso configurar mais nada
LAB 1-8-1 233

PTT
 Configurações BGP no router CLIENTE:
 OBS: onde houver Y substituiremos pelo AS que será TRÂNSITO, e Z.Z.Z.Z pelo IP que está
configurado do outro lado
AS-X-R1#conf t
AS-X-R1(config-router)#neighbor Z.Z.Z.Z description Acordo bilateral-transito IP
AS-X-R1(config-router)#neighbor Z.Z.Z.Z prefix-list MEUS-BLOCOS out
!--- como cliente devemos anunciar da mesma maneira que fizemos com os ASs de trânsito
!--- e já que o classe A local já está nessa lista não preciso configurar mais nada
LAB 1-8-1 234

PTT AS-X-R1#show ip bgp Y.0.0.0
Flag: 0x840
1
Y
1.125.1.2 from 1.125.1.2 (3.0.0.1)
ROUTER Origin IGP, metric 0, localpref 100, weight 25, valid, external, best
TRÂNSITO 200 3
200.X.1.1 from 200.1.1.1 (200.0.0.100)
Y
187.16.216.Y from 187.16.216.254 (187.16.216.254)
Y
187.16.216.3 from 187.16.216.253 (187.16.216.253)
100 Y
100.X.1.1 from 100.1.1.1 (100.0.0.100)
LAB 1-8-1 235

PTT AS-X-R1#show ip bgp Y.0.0.0
Flag: 0x840
1
Y
Z.Z.Z.Z from 1.125.1.2 (3.0.0.1)
ROUTER Origin IGP, metric 0, localpref 100, weight 25, valid, external, best
TRÂNSITO 200 3
200.X.1.1 from 200.1.1.1 (200.0.0.100)
Y
187.16.216.Y from 187.16.216.254 (187.16.216.254)
Y
187.16.216.3 from 187.16.216.253 (187.16.216.253)
100 Y
100.X.1.1 from 100.1.1.1 (100.0.0.100)
LAB 1-8-1 236

PTT
(...)

ROUTER BGP table version is 54, local router ID is X.0.0.1
TRÂNSITO Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,

*> X.0.0.0 0.0.0.0 0 32768 i
*> Y.0.0.0 1.125.1.2 0 25 3 i
LAB 1-8-1 237

PTT
 Testando o LAB:
● DESATIVEM as interfaces E1/0 e sE2/0 do AS que foi

designado como CLIENTE nesse LAB.
● Se tudo deu certo, os ASs que não participam do PTT

(123, 55,100,111,200 e 222) conseguirão alcançar o AS
do cliente através do AS que serviu como TRÂNSITO.
● O objetivo agora é que AS's que não participam do PTT

fiquem acessíveis (trânsito IP)
LAB 1-8-1 238

PTT
 Testando da internet a conectividade do AS CLIENTE após falha em seus links
principais...
AS-123-R1>show ip bgp Y.0.0.0

Flag: 0x820
2
55 111 100 X Y
123.55.1.2 from 123.55.1.2 (123.55.1.2)
222 200 X Y
123.222.1.2 from 123.222.1.2 (222.222.1.1)
LAB 1-8-1 239

PTT
principais...
AS-123-R1>show ip bgp Y.0.0.0

Flag: 0x820
2
55 111 100 X Y
123.55.1.2 from 123.55.1.2 (123.55.1.2)
222 200 X Y
123.222.1.2 from 123.222.1.2 (222.222.1.1)
LAB 1-8-1 240

PTT
principais...
AS-123-R1>ping Y.0.0.1

Sending 5, 100-byte ICMP Echos to Y.0.0.1, timeout is 2
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
56/72/96 ms
LAB 1-8-1 241

3.11
PERGUNTAS?
242
4.0
Filtros Básicos para um AS
de Trânsito
4. Filtros básicos para um AS de trânsito
• 4.1 eBGP com upstreams e downstreams

• 4.2 Configurando filtros de upstreams
• 4.3 Configurando filtros de downstreams
• 4.4 Entendendo o regexp
• 4.5 Enviando/recebendo partial e full-routing
• 4.6 Route-map x prefix-list
• 4.7 AS-Path Prepend
• 4.8 Engenharia de tráfego I
243
4.1
eBGP com Upstreams e

Downstreams
244
4.1 – eBGP com Upstreams e Downstreams
 Daqui por diante faremos referência à 3 tipos de sessões
BGP:
– IBGP (BGP interno): sessões BGP com routers

do meu próprio AS.
– eBGP UPSTREAM: sessões BGP com AS's

externos que prestam serviço de trânsito IP
para meu AS.
– eBGP DOWNSTREAM: sessões BGP com AS's

externos aos quais meu AS presta serviço de
trânsito IP.
245
 IBGP
● Sessões entre roteadores que fazem parte do mesmo
sistema autônomo
● Geralmente não utilizamos filtros
● Não importa a quantidade de saltos de roteamento, não

há incremento de AS-PATH
● O BGP identifica automaticamente sessões iBGP quando o

“remote-as” é o mesmo AS declarado em “router bgp X”
246
 eBGP – com UPSTREAMS

● Geralmente recebemos todas as rotas da internet
● Os filtros de ENTRADA são do tipo “lista negra”

✔ Bloqueio de alguns exceções
✔ Prioridade sempre menor que DOWNSTREAMS
● Os filtros de SAÍDA são do tipo “lista branca”

✔ Enviar apenas meus prefixos e prefixos de
DOWNSTREAMS
247
 eBGP – com DOWNSTREAMS

● Recebemos apenas prefixos do cliente e/ou clientes
secundários
● Os filtros de ENTRADA são do tipo “lista branca”

✔ Maior prioridade possível deve ser aplicada
● Os filtros de SAÍDA são do tipo “lista negra”

✔ Enviar todos os prefixos possíveis e bloquear exceções
✔ Anúncio de “parcial routing” apenas quando solicitado
248
4.2
Configurando Filtros de
Upstreams
249
4.2 - Configurando Filtros de Upstreams
 Não podemos anunciar nenhuma rede da qual não

queremos receber DOWNLOADS, para isso utilizamos
filtros em todas as nossas saídas de UPSTREAM e PTTs.
 Porém existem certas precauções que devem ser tomadas
nos filtros de entrada com UPSTREAMS:
– Não receber meus próprios prefixos;
– Não receber BOGONS;
– Não receber IPs privados;
– Não receber rotas cujo AS PATH contenham
AS(s) privado(s);
– Garantir que rotas de UPSTREAMS não
recebam prioridade maior que rotas
DOWNSTREAMS;
250
 ”Por padrão” o BGP descarta todas as rotas que anunciei e

voltaram para mim por algum motivo (multihoming por
exemplo).
!--- essa regra pode ser modificada utilizando o comando
!--- “router(config-router)#neighbor 192.168.2.1 allowas-in”
 Quando isso acontece, logo é verificado o meu próprio AS no
path e a rota é descartada automaticamente.
 Porém é possível que alguém anuncie por "engano", e a

única forma de garantir é um filtro baseado em IP (prefix-
list).
251
 Precisamos configurar alguns filtros padrão que evitam o

recebimento de grades de IPs privados, multcast, link
local, etc.
 Para isso vamos criar uma prefix-list chamada ”NAO-

RECEBER” e inserir nela todas as redes indesejadas.
 Para facilitar, o Cisco IOS permite especificar intervalos de

IPs, isso dispensa o trabalho de inserir cada sub-rede
manualmente.
 Vamos entender melhor...
252
 Antes de criar uma prefix-list no Cisco precisamos ter em

mente que para toda ela há um DENY implícito no final,
semelhante à uma ”lista branca”, onde quem estiver na
lista será permitido, e todo o resto bloqueado, ex:
Router (config)#ip prefix-list MINHA-LISTA permit 122.36.200.0/24
Router (config)#ip prefix-list MINHA-LISTA {NEGAR TUDO}

Reg
ra o
cult
a
 Com essa prefix-list na ENTRADA de um protocolo de

roteamento qualquer o resultado seria receber apenas
122.36.200.0/24, e qualquer outro prefixo seria
descartado.
 Lembrem que a última regra de {NEGAR TUDO} jamais
aparece, nem mesmo no ”show running-config”.
253
 O que é o ”seq” ?
● Ao inserir o comando:
Router(config)#ip prefix-list MINHA-LISTA permit 122.36.200.0/24
● Automaticamente o IOS insere um número de sequência:
Router#show running-config | begin MINHA-LISTA
ip prefix-list MINHA-LISTA seq 5 permit 122.36.200.0/24
● Caso adicionemos mais redes na mesma lista o número

de seq é incrementado em 5 automaticamente para cada
regra:
Router(config)#end
254
 O que é o ”seq” ?
● A razão para o incremento de ”5 em 5” é a possibilidade de
inserir uma regra ”no meio” especificando um ”número de
seq”:
Router(config)#ip prefix-list MINHA-LISTA seq 4 permit 10.0.30.0/24
● A regra recém criada seria processada primeiro do que todas as

outras:
● Pouco importa a ordem de processamento quando todas as regras são

de ”permit”
● O ”seq” só tem relevância quando há regras de deny e permit na
mesma prefix-list e/ou utilizamos ”ranges” com ”le/ge”
255
 Ranges de subredes - (le):

● Vamos agora considerar a necessidade de permitir sub-blocos:
● Essa regra permite 192.168.0.0/24, porém não permite
192.168.0.0/25, 192.168.0.128/25, 192.168.0.16/28 ou
qualquer outra sub-rede.
● Para incluir sub-redes utilizamos ”le”:
Router(config)#ip prefix-list MINHA-LISTA permit 192.168.0.0/24 le 29
● Com essa mudança, 192.168.0.0/25, 192.168.0.128/25,

192.168.0.16/28 ou qualquer outra sub-rede dentro começando
com 192.168.0 seria aceita, exceto redes /30, /31 e /32.
● Para permitir TUDO dentro do /24 incluindo /30, /31 e /32
trocaríamos o le 29 por le 32.
256
 Ranges de subredes - (ge):
● Diferente do le, o ge especifica o tamanho mínimo da máscara,
seu uso é mais apropriado em redes maiores.
Router(config)#ip prefix-list MINHA-LISTA permit 192.0.0.0/8 ge 18 le 26
● O /8 indica os bits que serão ”fixos”.
● Para esse exemplo, qualquer prefixo com os 8 primeiros bits

fixos em começando com 192 (11000000) e ainda com
máscara igual ou maior que /18 e igual ou menor que /26.
● Caso seja declarada uma máscara /0 (192.0.0.0/0) não

importariam os 8 primeiros bits e qualquer prefixo (começando
com qualquer coisa) seria aceito desde que sua máscara fosse
entre /18 e /26.
257
 Ranges de subredes - (ge):

● Quero aceitar qualquer prefixo /24 e descartar todo o resto:
Router(config)#ip prefix-list MINHA-LISTA permit 0.0.0.0/0 ge 24 le 24
● Quero aceitar TODOS os prefixos dentro de 200.233.16.0/20,

menos o primeiro /22:
Router(config)#ip prefix-list MINHA-LISTA seq 10 deny 200.233.16.0/22
Router(config)#ip prefix-list MINHA-LISTA seq 20 permit 200.233.16.0/20 le 32
!--- no cenario real geralmente são rejeitados os prefixos menores que /24 por BGP,
!--- utilizaremos no máximo ”le 24” para qualquer filtro (in – out)
!--- se posteriormente fosse necessário adicionar bloqueio de mais um /22,

!--- o bloqueio funcionaria apenas com um seq menor que ”20”
258
 Agora que compreendemos o funcionamento, vamos

continuar de onde paramos e criar uma prefix-list
chamada NAO-RECEBER.
 Dentro dela colocaremos todos os prefixos que não
desejamos receber.
 Por se tratar de uma ”lista negra” não podemos esquecer de
inserir uma regra que permita todo o resto no fim da
hierarquia.
259
 Inserindo os prefixos na lista:
AS-X-R1(config)#ip prefix-list NAO-RECEBER seq 10 deny X.0.0.0/8 le 32
!--- blocos do meu próprio AS
NAO INSERIR
AS-X-R1(config)#ip prefix-list NAO-RECEBER seq 20 deny 10.0.0.0/8 le 32 ESSA LINHA
!--- uso privado (neste lab estamos utilizando para grupo 10, favor nao bloquear este)
AS-X-R1(config)#ip prefix-list NAO-RECEBER seq 30 deny 172.16.0.0/12 le 32
!--- uso privado
!--- link-local (APIPA)
!--- loopbacks
!--- Documentação
!--- uso privado
!--- multicast
!--- reservado para uso futuro (para o fim do IPv6?)
AS-X-R1(config)#ip prefix-list NAO-RECEBER seq 500 permit 0.0.0.0/0 le 24
!--- Permitir todo o resto e ao mesmo tempo descartar qualquer prefixo
!--- mais específico que /24 como /25, /26, /27, etc
LAB 1-9-1 260

 Apenas criar a lista NAO-RECEBER não terá efeito se a mesma não for
declarada como filtro de ENTRADA dos UPSTREAMS, PEERING e PTT.
AS-X-R1(config-router)#neighbor 100.X.1.1 prefix-list NAO-RECEBER in
AS-X-R1(config-router)#neighbor 200.X.1.1 prefix-list NAO-RECEBER in
AS-X-R1(config-router)#neighbor 187.16.216.253 prefix-list NAO-RECEBER in
AS-X-R1(config-router)#neighbor 187.16.216.254 prefix-list NAO-RECEBER in
AS-X-R1(config-router)#neighbor (IP de peering) prefix-list NAO-RECEBER in
AS-X-R1(config-router)#neighbor (acordo bilateral) prefix-list NAO-RECEBER in
!--- Nesse caso apenas para quem é CLIENTE no acordo bilateral
!--- O AS que vende trânsito já tem uma prefix-list chamada BLOCOS-CLIENTE-AS-Y no IN
LAB 1-9-1 261

 O AS 123 vai anunciar vários IPs privados, vamos verificar se o

bloqueio está acontecendo corretamente:
 Existem 2 comandoS para verificar as rotas recebidas:
(routes e received-routes)
AS-X-R1#sh ip bgp neighbors 100.X.1.1 routes
!--- mostra todas as rotas APÓS a validação do “nexthop”
!--- e após todos os filtros de input
 Porém, se executarmos o segundo comando receberemos um

erro:
AS-X-R1#sh ip bgp neighbors 100.X.1.1 received-routes
% Inbound soft reconfiguration not enabled on 100.X.1.1
!--- mostra todas as rotas ANTES da validação do “nexthop”
!--- e ANTES de passar em todos os filtros de input
LAB 1-9-1 262

 Desmistificando o ”Soft reconfiguration inbound”:
 Para que serve de verdade?
263
 HARD reset:
 É a maneira menos recomendada de fazer um refresh nas rotas.
 A conexão TCP volta para o estado ”idle”.
 Há um pequeno intervalo antes da conexão iniciar novamente.
Router#clear ip bgp { * | A.B.C.D | peergroupname ASN }
 SOFT reset:
 Realiza o route refresh mantendo a sessão ativa .
 Pode ser dividido em ”outbound refresh” e ”inbound refresh”.
 Router#clear ip bgp { * | A.B.C.D | peergroupname | ASN } soft { out | in }
 Porém isso ainda não explica a função do ”soft reconfiguration inbound” ...
264
 Quando updates são bloqueados pelos filtros de ”input”, esses updates

são descartados pelo router, não sendo possível verificar informações
sobre essas rotas.
 Habilitar o ”soft reconfiguration inbound” para um neighbor reserva uma
área em memória para guardar informações de todas as rotas
recebidas desse neighbor, tornando possível verificar as rotas que
foram descartadas pelos filtros de ”input”.
 Habilitar o ”soft reconfiguration inbound” permitirá usar o comando:
GX-R1#sh ip bgp neighbors A.B.C.D received-routes

!--- exibe as rotas recebidas de A.B.C.D antes dos filtros de input
!--- inclusive rotas com next-hop inválido
265
 Vamos habilitar o ”Soft reconfiguration inbound” para todos os

neighbors:
GX-R1(config-router)#neighbor 100.X.1.1 soft-reconfiguration inbound
GX-R1(config-router)#neighbor 200.X.1.1 soft-reconfiguration inbound
GX-R1(config-router)#neighbor 187.16.216.253 soft-reconfiguration inbound
GX-R1(config-router)#neighbor 187.16.216.254 soft-reconfiguration inbound
GX-R1(config-router)#neighbor (IP de peering) soft-reconfiguration inbound
GX-R1(config-router)#neighbor (acordo bilateral) soft-reconfiguration inbound
GX-R1#clear ip bgp * soft
LAB 1-9-2 266

 Agora vamos tentar novamente executar o comando “... received-

routes”
 Primeiro pelo AS 200:
!--- todas as rotas ANTES do filtro ”NAO-RECEBER”
!--- todas as rotas APÓS do filtro ”NAO-RECEBER”
 Depois pelo AS 100:
!--- todas as rotas ANTES do filtro ”NAO-RECEBER”
!--- todas as rotas APÓS do filtro ”NAO-RECEBER”
LAB 1-9-2 267

 Também é possível verificar a “contagem” de uma determinada
prefix-list
AS-X-R1#sh ip prefix-list detail NAO-RECEBER
ip prefix-list NAO-RECEBER:
count: 8, range entries: 8, sequences: 5 - 40, refcount: 7
seq 5 deny X.0.0.0/8 le 32 (hit count: 0, refcount: 1)
seq 10 deny 172.16.0.0/12 le 32 (hit count: 2, refcount: 1)
seq 40 permit 0.0.0.0/0 le 24 (hit count: 21, refcount: 1)
Ou...
AS-X-R1#sh ip prefix-list detail NAO-RECEBER | exclude (hit count: 0)

ip prefix-list NAO-RECEBER:
count: 8, range entries: 8, sequences: 5 - 40, refcount: 7
seq 40 permit 0.0.0.0/0 le 24 (hit count: 41, refcount: 1)
LAB 1-9-1 268

 Outros BOGONS
● Existe outro range de IPs que não são privados, mas ainda
assim devem ser bloqueados.
● Existem blocos públicos de IPs que ainda não foram designados

pelas organizações responsáveis.
● Dessa forma é possível que alguém utilize essas redes com

intenções suspeitas.
● Onde conseguir uma lista atualizada?
269
 Melhor do que sair à procura de listas é estabelecer um peering com o

cymru.
 Para solicitar esse peering é preciso entrar em contato com

bogonrs@cymru.com com as seguintes informações:
● Número de AS;
● Ip(s) que o cymru fará peering com você;
● Se o equipamento suporta autenticação
MD5 para BGP;
● Chave pública GPG/PGP (opcional);
270
 Segundo o site a resposta com as informações chega em 2 dias

úteis em média
 Para mais informações acesse:

http://www.team-cymru.org/Services/Bogons/bgp.html
271
 Configurando a sessão BGP com Cymru...
Router(config)#router bgp X
Router(config-router)#neighbor x.x.x.x remote-as 65333
Router(config-router)#neighbor x.x.x.x ebgp-multihop 255
Router(config-router)#neighbor x.x.x.x weight 100
Router(config-router)#neighbor x.x.x.x description BOGONS CYMRU
Router(config-router)#neighbor x.x.x.x prefix-list SAIDA-CYMRU out
Router(config-router)#neighbor x.x.x.x route-map FILTRO-CYMRUBOGONS in
Router(config-router)#neighbor x.x.x.x password <senha cymru>
Router(config-router)#exit
272
 Adicionando as rotas recebidas em BLACKHOLE:
Router(config)#ip bgp-community new-format

!---habilita suporte à communities tipo xxxx:yyyy
Router(config)#ip route 192.0.2.1 255.255.255.255 null0
!---cria a rota de blackhole
Router(config)#ip community-list 10 permit 65333:888
!---adiciona a community 65333:888 na comm-list 10
Router(config)#route-map FILTRO-CYMRUBOGONS permit 10
!---entra as opções do route-map de entrada
Router(config-route-map)#match community 10
!---declara o conteudo da comm-list 10 para condição de math
Router(config-route-map)#set ip next-hop 192.0.2.1
!---para toda rota que fizer a condição mudar o next-hop para blackhole
Router(config)#ip prefix-list SAIDA-CYMRU seq 5 deny 0.0.0.0/0 le 32
!---garantir que nada será anunciado para o cymru
273
4.3
Configurando Filtros de
Downstreams
274
4.3 - Configurando Filtros de Downstreams
 A primeira coisa e se levar em conta é a prioridade maior

para os prefixos recebidos do meu downstream.
 Ao mesmo tempo, não podemos correr o risco de receber

um full-routing desse cliente por algum erro dele, caso
isso aconteça, todo meu upload passa a subir por esse
cliente.
275
 LAB: Um cliente de trânsito (downstream) deverá ser
ativado com as seguintes informações:
PEERING
AS-200 PTT-SP
AS-100  Cliente de trânsito:
E2/0 G4/0 F0/1  AS: 1XX
E1/0
● Bloco CIDR: 187.X.0.0/22
● IP de WAN: X.101.1.2
G5/0 CLIENTE
AS-X-R1 AS-1XX ● Interface G5/0
.1 .2
F0/0
X.101.1.0/30
.254
X.128.0.0/9
.1
LAB 1-7-1 276

 Configuração do lado operadora (Cisco)
AS-X-R1#conf t
AS-X-R1(config)#ip prefix-list BLOCOS-AS-1XX permit 187.X.0.0/22 le 24
!--- criando uma nova prefix-list e inserindo o bloco CIDR do cliente na mesma
AS-X-R1(config)#ip prefix-list MEUS-BLOCOS permit 187.X.0.0/22 le 24
!--- atualizando a prefix-list existente com mais um prefixo
AS-X-R1(config-router)#neighbor X.101.1.2 remote-as 1XX
AS-X-R1(config-router)#neighbor X.101.1.2 weight 30
AS-X-R1(config-router)#neighbor X.101.1.2 prefix-list BLOCOS-AS-1XX in
AS-X-R1(config-router)#neighbor X.101.1.2 default-originate
!--- filtro de ENTRADA para o DOWNSTREAM AS 10X + envio de rota padrao
 Como já usamos os pesos (weight) 10 15 e 20 utilizaremos 30

para downstreams.
LAB 1-10-1
277
 Configuração no cliente Mikrotik
 Antes vamos verificar a conectividade IP com o AS 10X e depois
se conectar à esse router via telnet:
AS-X-R1>ping X.101.1.2

!!!!!
AS-X-R1>telnet X.101.1.2
Trying X.101.1.2 ... Open
MikroTik v5.26
Login: admin
Não precisa
Password: sem senha de senha
[admin@AS-1XX-R1] >
LAB 1-10- 278

1
 Configurando BGP
[admin@AS-1XX-R1] > routing bgp instance add name=ebgp as=1XX router-id=187.X.0.1
[admin@AS-1XX-R1] > routing bgp peer add name=ebgp-as-X remote-address=X.101.1.1 remote-as=X

instance=ebgp out-filter=AS-X-OUT
[admin@AS-1XX-R1] > routing bgp network add network=187.X.0.0/22 synchronize=no
[admin@AS-1XX-R1] > routing filter add chain=AS-X-OUT prefix=187.X.0.0/22 action=accept

[admin@AS-1XX-R1] > routing filter add chain=AS-X-OUT action=discard
!-- Ao contrario do Cisco, os filtros do mikrotik não possuem uma action padrão de DISCARD
[admin@AS-1XX-R1] > interface bridge add name=loopback
[admin@AS-1XX-R1] > ip address add address=187.X.0.1/32 interface=loopback
!-- de volta do Cisco AS-X-R1 com o comando /quit
LAB 1-10- 279

1
 Verificando status do BGP
[admin@AS-1XX-R1] > routing bgp peer print status
Flags: X - disabled, E - established
0 E name="ebgp-as-1" instance=ebgp remote-address=X.101.1.1 remote-as=1
tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no
hold-time=3m ttl=255 in-filter="" out-filter=AS-X-OUT
address-families=ip default-originate=never remove-private-as=no
as-override=no passive=no use-bfd=no remote-id=X.0.0.1
local-address=X.101.1.2 uptime=2m7s prefix-count=14 updates-sent=1
updates-received=14 withdrawn-sent=0 withdrawn-received=0
remote-hold-time=3m used-hold-time=3m used-keepalive-time=1m
refresh-capability=yes as4-capability=yes state=established
OU SIMPLESMENTE...
[admin@AS-1XX-R1] > routing bgp peer print

# INSTANCE REMOTE-ADDRESS REMOTE-AS
0 E ebgp X.101.1.1 X
LAB 1-10- 280

1
 Verificando status do BGP
[admin@AS-10X-R1] > routing bgp peer print status
0 E name="ebgp-as-1" instance=ebgp remote-address=X.101.1.1 remote-as=1
tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no
hold-time=3m ttl=255 in-filter="" out-filter=AS-X-OUT
address-families=ip default-originate=never remove-private-as=no
as-override=no passive=no use-bfd=no remote-id=X.0.0.1
local-address=X.101.1.2 uptime=2m7s prefix-count=14 updates-sent=1
updates-received=14 withdrawn-sent=0 withdrawn-received=0
remote-hold-time=3m used-hold-time=3m used-keepalive-time=1m
refresh-capability=yes as4-capability=yes state=established
OU SIMPLESMENTE...
[admin@AS-101-R1] > routing bgp peer print

# INSTANCE REMOTE-ADDRESS REMOTE-AS
0 E ebgp X.101.1.1 X
LAB 1-10- 281

1
 Verificando rotas anunciadas/recebidas no BGP recém criado
[admin@AS-10X-R1] > routing bgp advertisements print ebgp-as-X
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
ebgp-... 187.X.0.0/22 X.101.1.2 igp
[admin@AS-10X-R1] > ip route print where received-from =ebgp-as-X

Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 0.0.0.0/0 X.101.1.1 20
1 ADb 1.0.0.0/8 X.101.1.1 20
2 ADb 2.0.0.0/8 X.101.1.1 20
3 ADb 3.0.0.0/8 X.101.1.1 20
4 ADb 55.0.0.0/8 X.101.1.1 20
5 ADb 100.0.0.0/8 X.101.1.1 20
(...)
[admin@AS-1XX-R1] > /quit
interrupted
[Connection to X.101.1.2 closed by foreign host]

AS-X-R1>
LAB 1-10- 282

1
 Vamos verificar no looking glass os anúncios dos downstreams..
AS-123-R1>show ip bgp 187.X.0.0

BGP routing table entry for 187.X.0.0/22, version 31
2
55 111 100 X 10X
123.55.1.2 from 123.55.1.2 (123.55.1.2)
222 200 X 10X
123.222.1.2 from 123.222.1.2 (222.222.1.1)
LAB 1-10- 283

1
 Vamos verificar no looking glass os anúncios dos downstreams..
AS-123-R1>traceroute 187.X.0.1

Tracing the route to 187.X.0.1
1 123.222.1.2 16 msec 12 msec 12 msec

2 222.222.1.2 [AS 222] 20 msec 36 msec 36 msec
3 222.200.1.2 [AS 222] 68 msec 48 msec 48 msec
5 187.X.0.1 [AS 10X] 88 msec 48 msec 64 msec
LAB 1-10- 284

1
 Notem que no estágio em que chegamos, utilizar “prefix-lists” está

se tornando dificil de escalar e “debugar” problemas, pois com
uma determinada quantidade de dowstreams, simplesmente não
conseguimos identificar a quem percentem os blocos de IP.
 Discutiremos posteriormente modelos mais fáceis de escalar com

“route-map”
LAB 1-10- 285

1
4.4
Entendendo o
”BGP REGEXP”
286
4.4 - Entendendo o “BGP REGEXP”
 Quando temos muitos clientes de trânsito é preciso estabelecer

padrões para que os administradores sejam capazes de
entender as configurações.
 Além de evitar ao máximo a quantidade excessiva de linhas de

configuração.
 Por exemplo:
Há um "range" de números de AS que são de uso privado

semelhantes aos IPs 192.168.x.x . Esse intervalo vai de 64512
até 65535, e não devemos receber anúncios que contenham
algum desses AS's no path.
287
 Imagine ter que configurar uma linha de deny para cada AS

privado.
Router(config)#ip as-path access-list 1 deny 64512

...
...
Router(config)#ip as-path access-list 1 permit .*
 Seria um tanto complicado!

 Felizmente com expressões regulares ao invés de milhares,
resolvo esse problema com apenas 2, (ou uma talvez).
288
“_” - Underline
✗ Substitui uma lista de expressões, que pode ser uma vírgula (,), chave esquerda ({), chave direita (}), o
início da seqüência de entrada (^), o fim da seqüência de entrada ($), ou um espaço.
✗ Escrever _444_ pode ser equivalente às seguintes combinações:
✗ ^444$
✗ ^444espaço
✗ espaço444
✗ {444,
✗ ,444,
✗ {444}
✗ ,444,
 Para praticar segue um link interessante:
 http://tools.lymas.com.br/regexp_br.php
289
 Antes vamos entender a função dos principais caracteres nas
expressões regulares:
✗ "1" Um número isolado satisfaz a condição para qualquer expressão que contenha esse número.
✗ exemplo1: 1 "a condição de match é qualquer AS no Path (podem haver vários AS's) que contenha o
número 1 em qualquer parte, em pelo menos um dos AS's.
Satisfaz: ”99199”, "123 432", "999 888 777 123 998".
Não satisfaz: "355 3344 22334", "466", etc.

✗ exemplo2: _1 "a condição de match é qualquer AS no Path (podem haver vários AS's) que contenha o
número 1 no ínicio de pelo menos um dos AS's e que essa ocorrência não seja a primeira”.
Satisfaz: "891 12333 3445 9999", "555 123 432", "1111 2222 4444".
Não satisfaz: "4333 21123", "4661" "21111 912222", etc.

✗ exemplo3: _1_ "a condição de match é qualquer AS no Path (podem haver vários AS's) que contenha o
número 1 sozinho em pelo menos um dos AS's e essa ocorrência pode ser a primeira e/ou a última.
✗ Satisfaz: "2333 1 3445 9999", "33 1", "433 4444 1 433", “1”
Não satisfaz: "333 222 555 12".

290
✗
”.” Satisfaz a condição para qualquer número no lugar do ponto
✗ exemplo: _4.5_ "a condição de match é qualquer AS PATH que contenha um AS de 3 dígitos onde 4 seja o
primeiro e 5 seja o último com qualquer número no meio e que contenha ou nao outros AS's (antes e
depois)
Satisfaz: "12 415 43", "2 425 3", "435" , "321 456 445 345"
Não satisfaz: "315", "123 4115", etc
✗ Exemplo: 4.5 "a condição de match é qualquer número de 3 ou mais dígitos que tenha 4 e 5 em qualquer
parte do AS PATH e com um dígito qualquer entre eles
Satisfaz: "23415", "43425", "435 3333", "445", "45587", "321 44459 345"
Não satisfaz: 315, 416, etc
291
✗ ”$” Satisfaz a condição para o tudo que o que for terminado com o caracter (ou expressão) ao
lado esquerdo de "$"
✗ exemplo1: 12$ "a condição de match é qualquer AS PATH em que os dois últimos dígitos sejam 1 e 2
respectivamente"
Satisfaz: ”4912”, "65012", "12312", "11112", "9932 9976 64912", "28135 17379 54312" ...
Não satisfaz: 13, 22, 129, 55413, 58752 …

✗ exemplo2: _12$ "a condição de math é qualquer AS PATH em que último AS seja 12"
Satisfaz: "12", "2335 12", "312 12", "111 12"
Não satisfaz: "444 112", "22", "12 229", "999 12 1111"
✗ exemplo3: 1.2$ "a condição de match é qualquer AS PATH em que seus últimos 3 dígitos do último AS
sejam: 1, qualquer coisa e 2 respectivamente"
Satisfaz: "123 45666 33 112", "444 122", "132", "1111 132", "444 65192", "60192"
Não satisfaz: "2333 222", “123”, “112 912”
292
✗ ”^” Satisfaz a condição para caracteres que comecem com o caracter (ou exprssão) após o ^
✗ exemplo1: ^1 "a condição de match é qualquer AS PATH que tenha o dígito 1 no início do primeiro AS do
PATH
satisfaz: "1111 9999 55443", "12345 6776", 12222, 19999
não satisfaz: 21111, 31211, 2, 3, 43111

✗ exemplo2: ^1.4 "a condição de match é qualquer AS PATH em que os 3 primeiros dígitos do primeiro as
sejam: 1, qualquer coisa e 4 respectivamente
Satisfaz: "124 4321", "12444", "1449", "19455 12333", "10466 55443 9900"
Não satisfaz: 195, 2124, 22444, 9104

✗ exemplo3: ^1..8$ "a condição de match é um AS PATH contento apenas um AS de 4 dígitos, onde o
primeiro dígito é 1, o segundo e o terceiro qualquer coisa e o quarto e último seja 8 respectivamente
Satisfaz: ”1008”, ”1248”, ”1118”, ”1228”, ”1998”, ”1888”
Não satisfaz: 10008, "1008 1008", "14448"
293
 ”*” Satisfaz a condição para qualquer caractere à esquerda do "*", inclusive nenhum, por isso
é preciso utilizar o caracter um espaço "_" branco em conjunto, pois sem espaço a
expressão perde o sentido, por exemplo, 1* satisfaria condição para qualquer coisa, e o
padrão intuitivo para "qualquer coisa/tudo" é ".*"
✗ exemplo1: 1_* "a condição de match é qualquer coisa que contenha o dígito 1 em qualquer
parte do AS"
satisfaz: "43431 9999 777 9999 8888(infinito...)”,” … 99 9991 345 666 654 5556...”
não satisfaz: 8872, "9987 2332", etc
✗ Exemplo2: .* "a condição de math é qualquer AS PATH de qualquer tamanho, com qualquer
combinação"
Satisfaz: TUDO
Não satisfaz: NADA
294
 ”\” Este caracter é usado quando os caracteres de condição também são caracteres de
expressão regular, por exemplo, se precisássemos de uma expressão para dinheiro, onde
a condição fosse "R$ 10,00" até "R$ 10,99", teríamos um grande problema, já que a
expressão necessária é "R$_10,..$" Notem que o "$" precisa aparacer como "condição" ao
mesmo tempo que é um caracter de expressão regular. Sendo assim, não funcionaria. O
caracter "\" é usado para declarar que o próximo caracter deverá ser interpretado como
"condição", ao invés de sua função normal. Assim, a expressão corretá ficaria "R\$_10,..$"
 ”Felizmente” não utilizaremos esse caracter para BGP
295
✗ ”[ ]” Satifaz a condição para qualquer um dos caracters dentro dos colchetes, mas apenas UM
deles. Há a possibilidade de utilizar intervalos entre os colchetes seguidos de hífem "-"
✗ Dentro dos colchetes o caracter "^" tem função de negação, O intervalo funciona da mesma
forma para as negações.
✗ exemplo1: ^9[249]5$ "a condição é um AS que contenha qualquer combinação de 3 dígitos sendo o
primeiro 9, o terceiro 5 e o do meio 2, 4 ou 9
Satisfaz: ”925”, ”945”, e ”995”
Não satisfaz: 915, 955, 965, etc

✗ exemplo2: ^9[5-7]5$ "mesma lógica do exemplo 1, porém o dígito do meio pode ser de 5 à 7"
Satisfaz: 955, 965 e 975

✗ exemplo3: ^9[^28]5$ "a condição de match é a mesma lógica dos exemplos 1 e 2 porém o digito do meio
não poderá ser 2 ou 8
Satistaz: todas as possibilidades de um ”9.5” "menos" 925 e 985.

✗ exemplo4: ^9[^5-8]5$ "a condição de match segue a mesma lógica dos exemplos 2 e 3 porém o dígito do
meio não pode estar no intervalo entre 5 e 8 (5,6,7 ou 8)
Satisfaz: todas as possibilidades "menos" 955, 965, 975 e 985
296
✗ ”|” O PIPE divide dois ou mais caracters em uma condiço "ou".
✗ exemplo1: 3(4|9)3 satisfaz: 343 ou 393 apenas mesmo comportamento de “3[49]3”
✗ exemplo2: ^5([0-3]|9)3$ satisfaz: 503, 513, 523, 533 e 593
 PS ( ) coloca uma expressão em evidência, sem eles o exemplo 2 aceitaria

5333333333333333333353333333333333333333333435465769733...
297
✗ ”+” Satisfaz a condição para uma(pelo menos) ou mais ocorrências do caracter (ou expressão)
anterior em qualquer parte
✗ exemplo1: ^([^ ]+)$ satisfaz: qualquer ASPATH que contenha apenas 1 AS
Aplicação prática: Filtrar para meu cliente apenas rotas que tenham um AS no path e nada mais
✗ “?” Satisfaz a condição para uma ou nenhuma ou uma ocorrencia do caracter (ou expressão) anterior
✗ exemplo1: ^([^ ]+)?$ satisfaz: qualquer rota que tenha no máximo um AS no PATH ou NENHUM
Aplicação prática: Filtrar para meu cliente apenas rotas que tenham um AS no path e também rotas
que não contenham NENHUM AS no PATH (rotas originadas localmente)
✗ ”{ }” especifica um número ou um intervalo de repetições para um caracter (ou expressão)

antecedente
✗ exemplo1: ^2{4}$ satisfaz: 2222 apenas
✗ exemplo2: ^2{4,6}$ satisfaz: 2222, 22222 e 222222
✗ exemplo3: ^1[0-3]{1,2}$ satisfaz: 100, 13, 10, 132, 12, 130
nao satisfaz: 14, 1031, 15, 1033

298
 Agora vamos raciocinar um pouco e utilizar as expressões que

aprendemos para bloquear o range dos AS's 64512 até 65535
utilizando o menor número possível de regras...
LAB 1-11-1 299

 LAB: O AS 123 vai gerar rotas com AS's privados, vamos aplicar filtros de
input para bloquear essas rotas:
AS-X-R1(config)#ip as-path access-list 1 deny _(6451[2-9]|645[2-9][0-9]|64[6-9]..|65...)_

!--- bloqueia de 64512 a 65535
!--- obs, não há AS maior que 65535
AS-X-R1(config)#ip as-path access-list 1 permit .*
!--- aceita todo o resto
!--- Vamos adicionar o mesmo prefix-list na entrada do AS 100
AS-X-R1(config-router)#neighbor 100.X.1.1 filter-list 1 in
AS-X-R1(config-router)#neighbor 200.X.1.1 filter-list 1 in
OBS: As expressões acima podem ser simplificadas ainda mais
LAB 1-11-1 300

AS-X-R1#show ip bgp neighbors 100.X.1.1 received-routes

(...)
* 123.123.0.0/16 100.1.1.1 0 100 111 55 123 64512 i
* 172.20.0.0 100.1.1.1 0 100 111 55 123 i
* 192.168.0.0 100.1.1.1 0 100 111 55 123 i
(...) as-path privado
Prefixos privados
AS-X-R1#show ip bgp neighbors 100.1.1.1 routes

(...)
Os prefixos indesejados não aparecem no último comando!
LAB 1-11-1 301

AS-X-R1#show ip bgp neighbors 100.X.1.1 received-routes

(...)
* 123.123.0.0/16 100.1.1.1 0 100 111 55 123 64512 i
* 172.20.0.0 100.1.1.1 0 100 111 55 123 i
* 192.168.0.0 100.1.1.1 0 100 111 55 123 i
(...)
AS-X-R1#show ip bgp neighbors 100.1.1.1 routes

(...)
Os prefixos indesejados não aparecem no último comando!
LAB 1-11-1 302

 Existem infinitas aplicações, por exemplo, descubro que o AS 12345

está com lentidão, crio políticas que diminuem a prioridade de
qualquer prefixo anunciado por esse AS
router(config)#ip as-path access-list 20 permit _12345_

!--- cria a ACL 20 e diz que qualquer AS PATH contendo 12345 está nela
router(config)#route-map UPSTREAM-1 permit 1

!--- Cria um route-map no topo da hierarquia
router(config-route-map)#set local-preference 90
!--- especifica a ação "mudar o local pref para 90"
router(config-route-map)#match as-path 20
!--- especifica quem irá receber a ação "set local pref 90"
router(config-route-map)#exit
!--- cria um route-map ”em branco”que aceita todo o resto sem modificações
LAB 1-11-1 303

 Precisamos nesse caso fazer o mesmo para todos os UPSTREAMS

!--- Cria um route-map no topo da hierarquia
!--- especifica a ação "mudar o local pref para 90"
!--- especifica quem irá receber a ação "set local pref 90"
!--- cria um route-map ”em branco”que aceita todo o resto sem modificações
LAB 1-11-1 304

 As expressões regulares não servem apenas para filtrar prefixos,

mas também para encontrar certas rotas entre as centenas de
milhares de uma tabela full
 Por exemplo:
 Quero saber quais rotas na minha RIB foram originadas pelo AS
6762 (TELECOM ITALIA SPARKLE S.p.A.)
BGPD-ALOG-SP# sh ip bgp regexp _6762$

...
*> 2.16.70.0/23 201.20.36.158 0 16397 6762 i
*> 2.16.140.0/23 201.20.36.158 0 16397 6762 i
*> 2.16.146.0/23 201.20.36.158 0 16397 6762 i
...
305
 Exemplo 2:
Quais rotas foram recebidas pela Intelig através do peering com
Embratel?
Router# sh ip bgp regexp _17379 4230_
...
*> 186.205.244.0/22 201.20.36.158 0 16397 17379 4230 28573 i
 Exemplo 3:
Quais ASs estão diretamente conectados (sem prepend) com o AS
4230 (EMBRATEL)?
Router# sh ip bgp regexp _4230 ([0-9]+)$
…
*> 23.61.118.0/23 201.20.36.158 0 16397 17379 4230 28573 i
*> 23.61.120.0/22 201.20.36.158 0 16397 17379 4230 28573 i
...
306
 Quais ASs estão diretamente conectados com meus upstreams ou

downstreams?
Router# sh ip bgp regexp ^([0-9]+_{0,1}){1,2}$

...
*> 216.72.166.0 201.20.36.157 0 16397 6505 i
*> 216.239.32.0/19 201.20.36.158 0 16397 15169 i
...
307
4.5
Enviando e Recebendo
“Partial” e “Full-Routing”
308
4.5 – Enviando e Recebendo “Partial” e
“Full-routing”
 Enviando parcial para o meu DOWNSTREAM
● O cliente deseja receber rotas do meu AS e meus outros
DOWNSTREAMS (no momento ainda não temos outros ;)
 A lógica é mesma, vamos utilizar a as-path acl "10".
AS-X-R1(config)#ip as-path access-list 10 permit ^([0-9]+)$
AS-X-R1(config-router)#neighbor X.101.1.2 filter-list 10 out
AS-1-R1(config-router)#end
AS-1-R1#clear ip bgp X.101.1.2
AS-1-R1#show ip bgp neighbors X.101.1.2 advertised-routes
Originating default network 0.0.0.0

(...)
*> 2.0.0.0 1.2.1.2 0 20 2 i
*> 100.0.0.0 100.1.1.1 0 0 100 i
*> 200.0.0.0/8 200.1.1.1 0 0 200 i
(...)
LAB 1-12-1 309

“Full-routing”
Originating default network 0.0.0.0 Enviando rota padrão ok

(...)
*> 2.0.0.0 1.2.1.2 0 20 2 i
*> 100.0.0.0 100.1.1.1 0 0 100 i
*> 200.0.0.0/8 200.1.1.1 0 0 200 i
(...)
LAB 1-12-1 310

“Full-routing”

(...)
*> 2.0.0.0 1.2.1.2 0 20 2 i
*> 100.0.0.0 100.1.1.1 0 0 100 i Não enviamos nossa
*> 200.0.0.0/8 200.1.1.1 0 0 200 i própria rede
(...)
LAB 1-12-1 311

“Full-routing”

(...) ??????
*> 2.0.0.0 1.2.1.2 0 20 2 i
*> 100.0.0.0 100.1.1.1 0 0 100 i Não enviamos nossa
*> 200.0.0.0/8 200.1.1.1 0 0 200 i própria rede
(...)
LAB 1-12-1 312

“Full-routing”
 Vamos entender porque...
AS-X-R1#show ip bgp regexp ^([^ ]+)$
 O comando acima mostra rotas com 1 AS no ASPATH, porém as

rotas originadas localmente (comando network) tem na
verdade 0 AS's no ASPATH
AS-X-R1#show ip bgp reg ^$

Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,

*> X.0.0.0 0.0.0.0 0 32768 i
LAB 1-12-1 313

“Full-routing”
 Para corrigir isso precisamos de mais uma linha na filter-list
AS-X-R1(config)#ip as-path access-list 10 permit ^$
AS-X-R1(config)#end
AS-X-R1#show running-config | include access-list 10

ip as-path access-list 10 permit ^([0-9]+)$
ip as-path access-list 10 permit ^$
AS-X-R1#clear ip bgp 1.101.1.2

AS-X-R1#show ip bgp neighbors 1.101.1.2 advertised-routes

*> X.0.0.0 0.0.0.0 0 32768 i
(...)
LAB 1-12-1 314

“Full-routing”
AS-X-R1(config)#end

ip as-path access-list 10 permit ^$ 2 linhas na filter-list

*> X.0.0.0 0.0.0.0 0 32768 i
(...)
LAB 1-12-1 315

“Full-routing”
AS-X-R1(config)#end

ip as-path access-list 10 permit ^$ 2 linhas na filter-list

*> X.0.0.0 0.0.0.0 0 32768 i Resolvido!
(...)
LAB 1-12-1 316

“Full-routing”
 Para aumentar para até 2 AS's eu coloco mais uma...
router(config)# ip as-path access-list 1 permit ^([0-9]+ [0-9+)$
router(config)# ip as-path access-list 1 permit ^([0-9]+)$
router(config)# ip as-path access-list 1 permit ^$
 Adicionar 3 regras seja um problema, mas é um problema se eu
quiser "visualizar" em um comando só, nesse caso fica um tanto
tosco dar 3 comandos diferentes. Felizmente há a opção de facilitar
com o PIPE...
router#sh ip bgp regexp ^([0-9]+ [0-9]+)$|^([0-9]+)$|^$
 Dessa forma consigo ver tudo e ao mesmo tempo criar uma regra que
"vale por 3"
(...continua)
317
“Full-routing”
 Porém ainda posso simplificar mais...
de ^([0-9]+ [0-9]+)$|^([0-9]+)$|^$
para ^(([0-9]+ [0-9]+)|([0-9]+)|())$
 Evidentemente ainda dá para melhorar, trocando a expressão

"qualquer
 número" [0-9]+" por "qualquer coisa q nao seja em branco" "[^ ]",
logo:
de ^([0-9]+ [0-9]+)$|^([0-9]+)$|^$
para ^(([^ ]+ [^ ]+)|([^ ]+)|())$
(...continua)
318
“Full-routing”
 Porém ainda posso simplificar mais...
de ^([0-9]+ [0-9]+)$|^([0-9]+)$|^$
para ^(([0-9]+ [0-9]+)|([0-9]+)|())$
 Evidentemente ainda dá para melhorar, trocando a expressão

"qualquer
 número" [0-9]+" por "qualquer coisa q nao seja em branco" "[^ ]",
logo:
de ^([0-9]+ [0-9]+)$|^([0-9]+)$|^$
para ^(([^ ]+ [^ ]+)|([^ ]+)|())$
(...continua)
319
“Full-routing”
 Mesmo ficando pouco intuitivo, tivemos uma boa redução na

quantidade de caracteres e linhas... (apenas 1)
router(config)#ip as-path access-list 1 permit ^(([^ ]+ [^ ]+)|([^ ]+)|

())$
 Agora imagine a dificuldade de escalar em demandas de 3 ou 4 AS's

para 3 => ^(([^ ]+)|([^ ]+ [^ ]+)|([^ ]+ [^ ]+ [^ ]+)|())$
para 4 => ^(([^ ]+)|([^ ]+ [^ ]+)|([^ ]+ [^ ]+ [^ ])|([^ ]+ [^ ]+ [^ ]+ [^]+)|
())$
 Essa expressão para "4" é impossível de digitar com pressa ;-)
(...continua) 320
“Full-routing”
 Então as chaves ajudam a eliminar as repetições inserindo um
intervalo de repetições dentro das chaves {}...
 Consigo diminuir essa expressão de:
^(([^ ]+)|([^ ]+ [^ ]+)|([^ ]+ [^ ]+ [^ ])|([^ ]+ [^ ]+ [^ ]+ [^ ]+)|())$
para:
^([^ ]+_{0,1}){0,4}$
 Ou seja, a palavra ([^ ]+_{0,1}) à esquerda de {0,4} pode se
repetir 0 vezes, 1
vez, 2 vezes, 3 vezes ou 4 vezes.
 Infelizmente, nas versões de IOS que otilizamos nesse curso as
chaves simplesmente não funcionam
 PS: No Quagga funciona 100%.
321
4.6
Route-Map x Prefix-List
322
4.6 – Route-Map X Prefix-List
 Políticas de filtro baseadas em ROUTE-MAP:

● Seq number: { 0 … 65535 }
● A ordem que esse route-map vai ser processado na hierarquia,
seguindo a mesma lógica dos ”seq” da prefix-list.
router(config)#route-map FILTROS-DE-ENTRADA permit 10

router(config-route-map)#match ip address prefix-list MUDAR-METRIC
router(config-route-map)#set metric 50
323

● Condições: match ip address prefix-list MUDAR-METRIC
● Para receber a ação ”permit” e as modificações opcionais (set
metric 50) o prefixo precisaria estar contido na prefix list
”MUDAR-METRIC”
● OBS: é possível estabelecer mais de uma condição, por
exemplo:
match ip address prefix-list MUDAR-METRIC
match as-path 10
match community 60
● Mas nesse caso é preciso que todas as condições sejam

atendidas, caso contrário, o route-map é ignorado e é
processado o próximo route-map na sequência
324

● Modificações: set metric 50
● Ao atender 100% das condições podem ser aplicadas
modificações opcionais nas rotas
● OBS: Também é possível realizar mais de uma modificação, por
exemplo:
● set local-preference 120

set weight 40
set community 123:321

325

● Route-map sem condições declaradas:
● Nesses casos TODAS as rotas receberão à ação {permit | deny}
e qualquer modificação opcional, que nesse exemplo foi alterar
o local preference para 200.

326

● Route-map sem condições declaradas:
● Caso hajam outros route-maps abaixo (números maiores de
seq) de um route-map sem condições declaradas, esses jamais
serão processados e serão totalmente inúteis.
router#sh running-config | begin TESTE

route-map TESTE permit 1
set weight 10
!
match ip address BLOCOS-CLIENTE-1
set metric 10
set local-preference 350
!
match as-path 20
!
327

● Quando um ”PERMIT” se transforma em ”DENY”
● Ao combinar route-map e prefix-lists, entendam o ”permit” da
prefix list como um ”faz parte da lista” e não como um
”aceitar” propriamente dito, pois a ação de ”aceitar” vai
depender do que for declarado na ”ação” do route-map.
● Se é um route-map com ação DENY, tudo que tiver como permit
na prefix list será bloqueado, por exemplo:
!
ip prefix-list A seq 5 permit 192.168.2.0/25
ip prefix-list A seq 10 deny 192.168.2.128/25
!
route-map TESTE deny 1
match ip address prefix-list A
!
! ● Nesse caso o prefixo 192.168.2.0/25 será bloqueado, enquanto
192.168.2.128/25 será permitido, porém inutilizado por causa da
regra de cima
328
4.7
AS-Path Prepend
329
4.7 - AS-Path Prepend
 Para manipular o download pra os prefixos do meu próprio

AS eu posso facilmente anunciar prefixos mais ou menos
específicos.
 Mas como AS de trânsito não tenho como pedir aos meus

clientes que modifiquem seus anúncios caso eu queira
usar um link específico.
 O AS PATH prepend adiciona números extras de AS no AS

PATH das rotas anunciadas para um determinado
neighbor.
330
 Exemplo1:
✔ Inserindo prepends do MEU AS na saída
(Router-E1)
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 10.7.1.0 mask 255.255.255.0
neighbor 10.0.1.2 remote-as 64800
neighbor 10.0.1.6 route-map prepend out
!
route-map prepend permit 10
set as-path prepend 65000 65000 65000
(Router-R2)
R2#show ip bgp
*>i10.7.1.0/24 10.0.1.1 0 100 0 65000 i
* 10.0.1.5 0 0 65000 65000 65000 65000 i
Fonte:http://wiki.nil.com/AS-path_prepending_(technical_details)
331
 Exemplo2:
✔ Inserindo prepends do AS REMOTO na entrada
(Router-R1)
router bgp 64800
no synchronization
bgp log-neighbor-changes
neighbor 10.0.1.1 route-map prependIn in
!
route-map prependIn permit 10
set as-path prepend last-as 2
(Router-R1)
R1#show ip bgp

*> 10.7.1.0/24 10.0.1.1 0 0 65000 65000 65000 i
Fonte:http://wiki.nil.com/AS-path_prepending_(technical_details)
332
4.8
Engenharia de Tráfego
I
333
4.8 – Engenharia de Tráfego I
 LAB: Todos os grupos configurar Upstreams +

Dowmstreams de acordo com os seguintes requisitos:
AS-123
✔ Apenas o DOWNLOAD do
AS-55
CLIENTE (AS10X) deverá AS-222
chegar pelo AS 100, de forma
que o DOWNLOAD do AS AS-111
LOCAL continuará chegando
pelo AS 200.
AS-100 AS-200
AS-X
DOWNLOAD CLIENTE:
DOWNLOAD AS LOCAL: AS-10X
LAB 1-13-1 334


AS-123
✔ Apenas o DOWNLOAD do
AS-55
CLIENTE (AS10X) deverá AS-222
chegar pelo AS 100, de forma
que o DOWNLOAD do AS AS-111
LOCAL continuará chegando
pelo AS 200.
AS-100 AS-200
AS-X
DOWNLOAD CLIENTE:
DOWNLOAD AS LOCAL: AS-10X
LAB 1-13-1 335

AS123
✔ O DOWNLOAD do CLIENTE (AS10X)
deverá chegar pelo AS 100,
AS55
AS222
AS111
AS200
AS100
ASX
AS10X
DOWNLOAD CLIENTE AS 10X:
DOWNLOAD AS LOCAL X:
LAB 1-13-1 336

AS123
✔ O DOWNLOAD do CLIENTE (AS10X)
deverá chegar pelo AS 100,
AS55
✔ O DOWNLOAD do AS LOCAL continuará
chegando pelo AS 200.
AS222
AS111
AS200
AS100
ASX
AS10X
DOWNLOAD CLIENTE AS 10X:
DOWNLOAD AS LOCAL X:
LAB 1-13-1 337

 Antes de começar precisamos desfazer algumas
configurações e em seguida aplicar as demais
AS-X-R1(config)#no ip prefix-list MEUS-BLOCOS
AS-X-R1(config)#ip prefix-list MEUS-BLOCOS permit X.0.0.0/8
!--- remove a prefix list MEUS-BLOCOS e refaz com apenas uma linha
!--- para remover prefixos antigos
AS-X-R1(config-router)#no neighbor 200.X.1.1 prefix-list MEUS-BLOCOS out
!--- desconfigura a prefix list MEUS-BLOCOS do filtro de saida do AS 200
AS-X-R1(config-router)#no neighbor 100.X.1.1 prefix-list MEUS-BLOCOS out
!--- desconfigura a prefix list MEUS-BLOCOS do filtro de saida do AS 200
AS-X-R1(config-router)#neighbor 200.X.1.1 route-map AS-200-OUT out
!--- configura o route-map AS-200-OUT como filtro de saída para o AS 200
AS-X-R1(config-router)#neighbor 100.X.1.1 route-map AS-100-OUT out
!--- configura o route-map AS-100-OUT como filtro de saída para o AS 100
(...)continua...
LAB 1-13-1 338

(...)
AS-X-R1(config)#route-map AS-100-OUT permit 10
!--- entra no modo de configuração do route-map seq 10
AS-X-R1(config-route-map)#match ip address prefix-list MEUS-BLOCOS
!--- declara a condição fazer parte da lista MEUS-BLOCOS para receber ”permit”,
AS-X-R1(config-route-map)#exit
AS-X-R1(config-route-map)#match ip address prefix-list BLOCOS-AS-10X
!--- declara a condição para receber ”permit”, porém sem inserir prepends
!--- entra no modo de configuração do route-map seq 10
!--- declara a condição fazer parte da lista MEUS-BLOCOS para receber ”permit”,
AS-X-R1(config-route-map)#set as-path prepend X X
!--- declara a condição para receber ”permit” + a modificação opcional prepend 2 vezes
!--- insere mais 2 vezes o AS local no AS PATH além de 1x padrão, total = 3
AS-X-R1(config-route-map)#end
LAB 1-13-1 339

 Testando o resultado com prefixo do cliente AS 10X
AS123
AS55
Flag: 0x820
Advertised to update-groups: AS222
1 AS111
55 111 100 X 10X
123.55.1.2 from 123.55.1.2 (123.55.1.2)
Origin IGP, localpref 100, valid, external, best AS200
AS100
222 200 X X X 10X
123.222.1.2 from 123.222.1.2 (222.222.1.1)
ASX
AS10X
LAB 1-13-1 340

AS123
AS55
AS222
1 123.55.1.2 24 msec 12 msec 16 msec AS111
2 55.55.1.2 [AS 55] 16 msec 36 msec 36 msec
3 55.111.1.2 [AS 55] 64 msec 48 msec 44 msec
4 111.111.1.2 [AS 111] 48 msec 68 msec 64 msec AS200
AS100
5 111.100.1.2 [AS 111] 97 msec 84 msec 88 msec
7 187.X.0.1 [AS 10X] 76 msec 84 msec 88 msec
ASX
AS10X
LAB 1-13-1 341

 Testando o resultado com prefixo do AS local X
AS123
AS-123-R1>show ip bgp X.0.0.1
AS55
2 AS222
222 200 X AS111
123.222.1.2 from 123.222.1.2 (222.222.1.1)
55 111 100 X AS200
AS100
123.55.1.2 from 123.55.1.2 (123.55.1.2)
ASX
AS10X
LAB 1-13-1 342

AS123
AS55
AS222
1 123.222.1.2 24 msec 16 msec 16 msec AS111
2 222.222.1.2 [AS 222] 16 msec 36 msec 36 msec
3 222.200.1.2 [AS 222] 68 msec 48 msec 44 msec
4 200.X.1.2 [AS 200] 48 msec 42 msec 44 msec AS200
AS100
ASX
AS10X
LAB 1-13-1 343

AS123
AS55
AS222
1 123.222.1.2 24 msec 16 msec 16 msec AS111
2 222.222.1.2 [AS 222] 16 msec 36 msec 36 msec
3 222.200.1.2 [AS 222] 68 msec 48 msec 44 msec
4 200.X.1.2 [AS 200] 48 msec 42 msec 44 msec AS200
AS100
ASX
AS10X
LAB 1-13-1 344

4.8
PERGUNTAS?
345
5.0
Roteamento
dentro do AS (iBGP)
346
5.0
Roteamento
dentro do AS (iBGP)
5. Roteamento dentro do AS (iBGP)
• 5.1 Implementando múltiplas saídas para clientes de trânsito

• 5.2 Update-source
• 5.3 Next-hop-self
• 5.4 BGP Synchronization
• 5.5 Route-reflector
• 5.6 Peer groups
• 5.7 Local Preference x Weight no iBGP
• 5.8 Engenharia de Tráfego II
347
5.1
Implementando Múltiplas
Saídas para Clientes de
Trânsito
348
5.1 - Implementando Múltiplas Saídas para
Clientes de Trânsito
 Conforme discutido anteriormente, o BGP é um protocolo
desenvolvido para troca de rotas entre AS's distintos.
 Deve ser evitado dentro do AS, a menos que as extremidades
precisem trocar rotas de AS's externos.
 Em outras palavras, se houver realmente a necessidade de
entregar para um DOWNSTREAM rotas recebidas de um
UPSTREAM.
 No exemplo abaixo não há necessidade de injetar rotas externas
dentro do AS:
349
 Injetar rotas externas se faz necessário apenas quando essas
precisam ”atravessar” o AS.
 Em outras palavras, se houver realmente a necessidade de
entregar para um DOWNSTREAM rotas recebidas de um
UPSTREAM.
 No exemplo as rotas recebidas do AS 20 e 30 precisam chegar ao
AS 50 e vice-versa.
350
 Alguns pontos importantes:
1. Um protocolo de roteamento IGP precisa garantir conectividade IP
entre TODOS os routers do AS.
2. Mas se não houver múltiplos caminhos, não há necessidade de IGP,
apenas rotas estáticas.
351
 Em nosso LAB há múltiplos caminhos, e todos os routers (exceto
AS's externos) já estão configurados com OSPF:
PTT-RJ
PTT-SP 40X
50X 50Z
100
R2 R5 50X
200
AS-X
R3
610XX
R1 R4 40X
peering
10X
IP's e interfaces detalhados em:
goo.gl/kIcIbX
352
40Z
50X
50Z
100
R2 R5 50X
200
AS-X
R3
610XX
R1 R4 40X
10X
353
5.1 - Implementando Múltiplas Saídas
para Clientes de Trânsito
 LAB: Considerando que as cidades onde ficam R4 e R5 atendem
clientes de trânsito (DOWNSTREAMS), e as cidades onde ficam
R1 e R2 tem saída de trânsito IP (UPSTREAMS) e PTT,
precisaremos que R4 e R5 recebam e enviem rotas para o AS 100
(através de R1), e para o AS 200 através de R2.
 Vamos estabelecer sessões eBGP entre os clientes de trânsito AS

40X com R4 e AS 50X com R5.
NOTA:
!--- No intuito de facilitar a visualização das rotas, em

!--- todos os LABS seguintes não trabalharemos com anúncios mais
!--- específicos que /8, (com excessão dos anúncios ao PTT no lab
!--- correspondente
LAB 2-1-1 354

BGP ENTRE
AS-X-R4 E AS-40X-R1
LAB 2-1-1 355

R4
AS-X-R4
LAB 2-1-1 356

 Configurando eBGP com o

downstream: AS 40X em R4:
● LADO DA OPERADORA
AS-X-R4#conf t R4
AS-X-R4(config)#ip prefix-list BLOCOS-AS-40X permit 154.X.0.0/16 le 24
!--- adiciona os blocos CIDR do DOWNSTREAM nesa prefix-list que será
!--- referenciada nas configurações BGP a seguir...
AS-X-R4(config-router)#bgp router-id X.0.0.4
!--- esse comando é meramente ilustrativo pois o router ID de R1 já esse RouterID
AS-X-R4(config-router)#synchronization
AS-X-R4(config-router)#neighbor X.104.1.2 remote-as 40X
AS-X-R4(config-router)#neighbor X.104.1.2 description eBGP downstream AS-40X
AS-X-R4(config-router)#neighbor X.104.1.2 soft-reconfiguration inbound
AS-X-R4(config-router)#neighbor X.104.1.2 prefix-list BLOCOS-AS-40X in
!--- declara o filtro de entrada para rotas recebidas desse DOWNSTREAM
LAB 2-1-1 357

40X-R1
AS-40X-R1
LAB 2-1-1 358

 Antes vamos testar conectividade e entrar
no Juniper...
Type escape sequence to abort. 40X-R1

Sending 5, 100-byte ICMP Echos to X.104.1.2, timeout is 2 seconds:
.!!!!
AS-X-R4>
AS-X-R4>telnet X.104.1.2
AS-40X-R1 (ttyp0)
login: juniper
Password: juniper.123
--- JUNOS 12.2R2.4 built 2012-11-15 13:13:55 UTC

juniper@AS-40X-R1>
LAB 2-1-1 359


downstream: AS 40X em AS-40X-R1:
● LADO DO CLIENTE
juniper@AS-401-R1> configure 40X-R1
Entering configuration mode
[edit]
juniper@AS-401-R1#
set routing-options autonomous-system 40X
set protocols bgp group eBGP-upstream-AS-X type external
set protocols bgp group eBGP-upstream-AS-X export AS-X-OUT
set protocols bgp group eBGP-upstream-AS-X peer-as X
set protocols bgp group eBGP-upstream-AS-X neighbor X.104.1.1
LAB 2-1-1 360


● LADO DO CLIENTE
juniper@AS-40X-R1# show protocols bgp group eBGP-upstream-AS-X 40X-R1
type external;
export AS-X-OUT; ## 'AS-X-OUT' is not defined
peer-as X;
neighbor X.104.1.1;
No JunOS qualquer referência à uma policy que não existe

fica com alerta e o sistema proibe aplicar tal configuração:
LAB 2-1-1 361


● LADO DO CLIENTE
type external;
peer-as X;
neighbor X.104.1.1;
juniper@AS-40X-R1# commit
error: Policy error: Policy AS-X-OUT referenced but not defined
[edit protocols bgp group eBGP-upstream-AS-X]
'export'
BGP: export list not applied
error: configuration check-out failed
[edit]
juniper@AS-40X-R1#
LAB 2-1-1 362


downstream: AAS 40X em AS-40X-R1:
● LADO DO CLIENTE
type external;
peer-as X;
neighbor X.104.1.1;
error: Policy error: Policy AS-X-OUT referenced but not defined
[edit protocols bgp group eBGP-upstream-AS-X]
'export'
BGP: export list not applied
error: configuration check-out failed
[edit]
juniper@AS-40X-R1#
É preciso declarar essa policy para
conseguir aplicar as configurações
LAB 2-1-1 363

● LADO DO CLIENTE
(...) 40X-R1
[edit]
juniper@AS-40X-R1#
set policy-options policy-statement AS-X-OUT term 1 from route-filter 154.X.0.0/16 exact
set policy-options policy-statement AS-X-OUT term 1 then accept
set policy-options policy-statement AS-X-OUT then reject
set interfaces lo0 unit 0 family inet address 154.X.0.1/32
set routing-options static route 154.X.0.0/16 discard
LAB 2-1-1 364


● LADO DO CLIENTE
[edit] 40X-R1
juniper@AS-40X-R1# show policy-options policy-statement AS-X-OUT
term 1 {
from {
route-filter 154.X.0.0/16 exact;
}
then accept;
}
then reject;
[edit]
juniper@AS-40X-R1#
LAB 2-1-1 365

● LADO DO CLIENTE
juniper@AS-40X-R1# set routing-options static route 154.X.0.0/16 discard; 40X-R1
[edit]
juniper@AS-40X-R1# show interfaces lo0
unit 0 {
family inet {
address 154.X.0.1/32;
}
}
[edit]
commit complete
[edit]
juniper@AS-401-R1#

LAB 2-1-1 366

 Verificando status da sessão BGP...
juniper@AS-40X-R1> show bgp summary 40X-R1

Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State #Active/Received/Accepted/Damped...
X.104.1.1 X 8 11 0 0 3:02 0/0/0/0 0/0/0/0
LAB 2-1-1 367

 Verificando prefixos anunciados na sessão BGP
● LADO DO CLIENTE
juniper@AS-40X-R1> show route advertising-protocol bgp X.104.1.1 40X-R1

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 154.X.0.0/16 Self I
LAB 2-1-1 368

BGP ENTRE
AS-X-R5 E AS-50X-R1
LAB 2-1-1 369

R5
AS-X-R5
LAB 2-1-1 370


AS-X-R5#conf t R5
!--- adiciona os blocos CIDR do DOWNSTREAM nesa prefix-list que será
!--- declarada nas configurações BGP a seguir
AS-X-R5(config-router)#neighbor X.105.1.2 remote-as 50X
AS-X-R5(config-router)#neighbor X.105.1.2 description eBGP downstream AS-50X
AS-X-R5(config-router)#neighbor X.105.1.2 prefix-list BLOCOS-AS-50X in
!--- declara o filtro de entrada para rotas recebidas desse DOWNSTREAM
LAB 2-1-1 371

R1
AS-50X-R1
LAB 2-1-1 372

no Vyatta...

.!!!! R1
AS-1-R5>teln
AS-1-R5>telnet X.105.1.2
EN HA
Welcome to Vyatta AR IO/S
SU
U
AS-501-R1 login: vyatta
Password vyatta:
Last login: Tue Jan 20 08:53:46 GMT 2015 on tty1
Linux AS-50X-R1 2.6.37-1-amd64-vyatta #1 SMP Thu Jul 7 21:55:23 PDT 2011 x86_64
Welcome to Vyatta.
This system is open-source software. The exact distribution terms for
each module comprising the full system are described in the individual
files in /usr/share/doc/*/copyright.
vyatta@AS-50X-R1:~$
LAB 2-1-1 373

● LADO DO CLIENTE
vyatta@AS-50X-R1:~$ configure R1
[edit]
vyatta@AS-50X-R1#
set protocols bgp 50X network 155.X.0.0/16
set protocols bgp 50X neighbor X.105.1.1 remote-as X
set protocols bgp 50X neighbor X.105.1.1 prefix-list export MEUS-BLOCOS
set protocols bgp 50X neighbor X.105.1.1 soft-reconfiguration inbound
set policy prefix-list MEUS-BLOCOS rule 10 prefix 155.X.0.0/16
set policy prefix-list MEUS-BLOCOS rule 10 action permit
set interfaces loopback lo address 155.X.0.1/32
set protocols static route 155.X.0.0/16 blackhole
vyatta@AS-50X-R1# commit
[edit]
vyatta@AS-50X-R1#save
Saving configuration to '/config/config.boot'...
Done
LAB 2-1-1 374

 Verificando o status da sessão BGP
 vyatta@AS-50X-R1# run show ip bgp summary
BGP router identifier 155.X.0.1, local AS number 50X
RIB entries 1, using 96 bytes of memory
Peers 1, using 4560 bytes of memory

X.105.1.1 4 1 3 5 0 0 0 00:01:33 0
Total number of neighbors 1

[edit]
LAB 2-1-1 375

 Verificando prefixos anunciados na sessão BGP
vyatta@AS-50X-R1# run show ip bgp neighbors X.105.1.1 advertised-routes R1

 BGP table version is 0, local router ID is 155.X.0.1
r RIB-failure, S Stale, R Removed

*> 155.X.0.0 X.105.1.2 0 32768 i

[edit]
vyatta@AS-50X-R1#
LAB 2-1-1 376

R1
AS-X-R1
LAB 2-1-1 377

 Vamos também ajustar as configurações em R1.
AS-X-R1(config)# ip prefix-list BLOCOS-AS-40X permit 154.X.0.0/16 le 24
!--- Criando as prefix-lists dos clientes AS 40X e 50X R1
AS-X-R1(config)#route-map AS-10X-IN permit 10
AS-X-R1(config-route-map)#set local-preference 300
!--- Configurando o route-map que o IN do cliente AS-10X
(...)
LAB 2-1-1 378

 Inserindo os prefixos bloqueados para uso da prefix-list
com route-map:
AS-X-R1(config)#ip prefix-list BLOQUEADOS seq 10 permit X.0.0.0/8 le 32
NAO INSERIR
AS-X-R1(config)#ip prefix-list BLOQUEADOS seq 20 deny 10.0.0.0/8 le 32 ESSA LINHA
AS-X-R1(config)#ip prefix-list BLOQUEADOS seq 30 permit 172.16.0.0/12 le 32
!--- uso privado
!--- loopbacks
!--- Documentação
!--- uso privado
!--- multicast
!--- reservado para uso futuro
LAB 1-9-1 379

 Filtros de entrada e saída com o AS 100
(...)
AS-X-R1(config)#route-map AS-100-IN deny 10
AS-X-R1(config-route-map)#match ip address prefix-list BLOQUEADOS
AS-X-R1(config)#route-map AS-100-IN permit 999
AS-X-R1(config-route-map)#exit R1
!--- Essas linhas já existem
!-- vamos acrescentar apenas as seguintes...
(...)
LAB 2-1-1 380

 Filtros de entrada e saída com o AS 200
(...)
AS-X-R1(config-route-map)#exit R1
!--- Essas linhas já existem
!-- vamos acrescentar apenas as seguintes...
(...)
LAB 2-1-1 381

 Filtros de entrada e saída com o PTT-SP
(...)
AS-X-R1(config)#route-map PTT-SP-IN deny 10
AS-X-R1(config)#route-map PTT-SP-IN permit 999
AS-X-R1(config-route-map)#set local-preference 120 R1
AS-X-R1(config)#route-map PTT-SP-OUT permit 10

LAB 2-1-1 382

 Vamos também ajustar as de todas
sessões eBGP
AS-X-R1(config-router)#bgp router-id X.0.0.1 R1
AS-X-R1(config-router)#network X.0.0.0
AS-X-R1(config-router)# neighbor X.101.1.2 remote-as 10X
AS-X-R1(config-router)# neighbor X.101.1.2 description downstream AS-10X
AS-X-R1(config-router)# neighbor X.101.1.2 default-originate
AS-X-R1(config-router)# neighbor X.101.1.2 weight 30
AS-X-R1(config-router)# neighbor X.101.1.2 soft-reconfiguration inbound
AS-X-R1(config-router)# neighbor X.101.1.2 route-map AS-10X-IN in
AS-X-R1(config-router)# neighbor X.101.1.2 filter-list 10 out
AS-X-R1(config-router)# neighbor 100.X.1.1 description upstream AS-100
AS-X-R1(config-router)# neighbor 100.X.1.1 soft-reconfiguration inbound
AS-X-R1(config-router)# neighbor 100.X.1.1 route-map AS-100-IN in
AS-X-R1(config-router)# neighbor 100.X.1.1 route-map AS-100-OUT out
AS-X-R1(config-router)# neighbor 100.X.1.1 filter-list 1 in
LAB 2-1-1 383
(...)
AS-X-R1(config-router)# neighbor 200.X.1.1 route-map AS-200-IN in R1
AS-X-R1(config-router)# neighbor 187.16.216.252 remote-as 555
AS-X-R1(config-router)# neighbor 187.16.216.252 description PTT-SP Lookin Glass
AS-X-R1(config-router)# neighbor 187.16.216.253 description PTT-SP Router Server 1
AS-X-R1(config-router)# neighbor 187.16.216.253 weight 15
AS-X-R1(config-router)# neighbor 187.16.216.253 route-map PTT-SP-IN in
AS-X-R1(config-router)# neighbor 187.16.216.253 route-map PTT-SP-OUT out
AS-X-R1(config-router)# neighbor 187.16.216.254 description PTT-SP Router Server 2
AS-X-R1(config-router)# neighbor 187.16.216.254 route-map PTT-SP-IN in
AS-X-R1(config-router)# neighbor 187.16.216.254 route-map PTT-SP-OUT out
AS-X-R1(config-router)# end
AS-X-R1# clear ip bgp *
LAB 2-1-1 384
R2
AS-X-R2
LAB 2-1-1 385

AS-X-R2(config)# ip prefix-list MEUS-BLOCOS permit X.0.0.0/8 R2
!--- Criando as prefix-lists dos clientes AS 10X, 40X, 50X e blocos do AS local
AS-X-R2(config)#ip as-path access-list 1 deny _(6451[2-9]|645[2-9][0-9]|64[6-9]..|65...)_
!--- deny de 64512 a 65535
AS-X-R2(config)#ip as-path access-list 1 permit .*
!--- aceita todo o resto
(...)
LAB 2-1-1 386

 Inserindo os prefixos bloqueados para uso da prefix-list
com route-map:
AS-X-R2(config)#ip prefix-list BLOQUEADOS seq 10 permit X.0.0.0/8 le 32
NAO INSERIR
AS-X-R1(config)#ip prefix-list BLOQUEADOS seq 20 deny 10.0.0.0/8 le 32 ESSA LINHA
!--- uso privado
!--- loopbacks
!--- Documentação
!--- uso privado
!--- multicast
!--- reservado para uso futuro
LAB 1-9-1 387

 Filtros de saída com o AS 100
(...)
AS-X-R2(config)#route-map AS-100-IN permit 999 R2
(...)
LAB 2-1-1 388

 Filtros de saída com o AS 200
(...)
AS-X-R2(config)#route-map AS-200-IN permit 999 R2
(...)
LAB 2-1-1 389

 Filtros de entrada e saída com o PTT-RJ
(...)
AS-X-R2(config)#route-map PTT-RJ-IN deny 10
AS-X-R2(config)#route-map PTT-RJ-IN permit 999 R2
AS-X-R2(config)#route-map PTT-RJ-OUT permit 10
LAB 2-1-1 390

sessões eBGP
AS-X-R2(config-router)#synchronization R2
LAB 2-1-1 391

sessões eBGP
AS-X-R2(config-router)#synchronization R2
AS-X-R2(config-router)# neighbor 100.X.2.1 route-map AS-100-OUT
ATEN ÇÃO NO IP out
LAB 2-1-1 392

sessões eBGP
(...)
AS-X-R2(config-router)# neighbor 200.219.138.252 description PTT-RJ Lookin Glass
R2
AS-X-R2(config-router)# neighbor 200.219.138.253 description PTT-RJ Router Server 1
AS-X-R2(config-router)# neighbor 200.219.138.253 route-map PTT-RJ-IN in
AS-X-R2(config-router)# neighbor 200.219.138.253 route-map PTT-RJ-OUT out
AS-X-R2(config-router)# neighbor 200.219.138.254 description PTT-RJ Router Server 2
AS-X-R2(config-router)# neighbor 200.219.138.254 route-map PTT-RJ-IN in
AS-X-R2(config-router)# neighbor 200.219.138.254 route-map PTT-RJ-OUT out
AS-X-R2(config-router)# end
AS-X-R2# clear ip bgp *
LAB 2-1-1 393

R1
AS-X-R1
LAB 2-1-1 394

 Configurando iBGP entre R1 e R4:
AS-X-R1#conf t
AS-X-R1(config)#router bgp X R1
AS-X-R1(config-router)#neighbor X.0.0.5 remote-as X
AS-X-R1(config-router)#neighbor X.0.0.5 description iBGP AS-X-R5
AS-X-R1#conf t
R1
LAB 2-1-1 395

R4
AS-X-R4
LAB 2-1-1 396

AS-X-R4#conf t
AS-X-R4#conf t
R4
LAB 2-1-1 397

R5
AS-X-R5
LAB 2-1-1 398

AS-X-R5#conf t
AS-X-R5#conf t
R5
LAB 2-1-1 399

R2
AS-X-R2
LAB 2-1-1 400

AS-X-R2#conf t
 Configurando iBGP entre R2 e R5
AS-X-R2#conf t
R2
LAB 2-1-1 401

5.1
PERGUNTAS?
402
5.2
Update-Source
403
5.2 - Update-source
 As sessões iBGP subiram?
– Provavelmente não!
– Por que razão?
404
5.2 - Update-source
 Como decidimos estabelecer as sessões utilizando os IPs de

loopback dos routers internos, nos deparamos com um
problema no extabelecimento da conexão TCP.
405
5.2 - Update-source
 A menos que especifiquemos algo diferente, o IP de origem

de todo pacote é o IP da interface que saiu.
 Em outras palavras, se a melhor rota para alcançar R4 é

pela serial 1/1, o IP de origem será o IP dessa interface.
406
5.2 - Update-source
 Vejamos:
AS-X-R4#sh ip route X.0.0.1

Routing entry for X.0.0.1/32
Known via "ospf 1", distance 110, metric 129, type intra area
Last update from X.X.4.1 on Serial1/0, 07:43:20 ago
Routing Descriptor Blocks:
* X.X.4.1, from X.0.0.1, 07:43:20 ago, via Serial1/0
Route metric is 129, traffic share count is 1
 Nesse caso, quando o pacote "syn" chegar ao router R1 ( X.0.0.1)

para solicitar o início da sessão BGP, o seu IP de origem desse
pacote será X.X.4.2, e já que R1 foi configurado para
estabelecer BGP com X.0.0.4 (R4) ele naturalmente rejeita essa
conexão.
407
5.2 - Update-source
 Analisando o BGP debug:
07:42:42: BGP: X.0.0.1 open active, delay 7672ms

07:42:50: BGP: X.0.0.1 open active, local address X.X.4.2
07:42:50: BGP: X.0.0.1 open failed: Connection refused by remote host
408
5.2 - Update-source
 Para resolver esse problema precisamos dizer ao meu router R4

que utilize o IP X.0.0.4 para estabelecer a conexão TCP-179
com R1:
AS-X-R4(config-router)#neighbor X.0.0.1 update-source loopback 0
!--- loopback 0 é a interface que possui o IP X.0.0.4 no R4
!--- mas também podemos declarar um IP ao invés de uma interface
LAB 2-1-2 409

5.2 - Update-source
 Analisando novamente o debug após a mudança no updade

source:
07:48:50: BGP: X.0.0.1 open active, local address X.0.0.4
07:48:50: BGP: X.0.0.1 went from Active to OpenSent
07:48:50: BGP: X.0.0.1 sending OPEN, version 4, my as: X
07:48:50: BGP: X.0.0.1 rcv message type 1, length (excl. header) 26
07:48:50: BGP: X.0.0.1 rcv OPEN, version 4
07:48:50: BGP: X.0.0.1 rcv OPEN w/ OPTION parameter len: 16
07:48:50: BGP: X.0.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
07:48:50: BGP: X.0.0.1 OPEN has CAPABILITY code: 1, length 4
07:48:50: BGP: X.0.0.1 OPEN has MP_EXT CAP for afi/safi: 1/1
07:48:50: BGP: X.0.0.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
07:48:50: BGP: X.0.0.1 OPEN has ROUTE-REFRESH capability(new) for all address-families
07:48:50: BGP: X.0.0.1 went from OpenSent to OpenConfirm
07:48:50: BGP: X.0.0.1 went from OpenConfirm to Established
07:48:50: %BGP-5-ADJCHANGE: neighbor X.0.0.1 Up
LAB 2-1-2 410

5.2 - Update-source
 … fazer a mesma mudança em R5:
!--- loopback 0 é a interface que possui o IP X.0.0.5 no R5
07:48:50: %BGP-5-ADJCHANGE: neighbor X.0.0.1 Up
LAB 2-1-2 411

5.2 - Update-source
 Por que não foi necessário realizar a mesma configuração em R1?
✔ Por que o R1 responde (com a mensagem type 1)

utilizando o IP destino que R4 inseriu no pacote de
"OPEN" (X.0.0.1).
 Na prática é preciso que apenas um dos dois routers altere o

"update-source", porém é recomendável alterar nos dois, pois
isso pode fazer com que a sessão estabeleça alguns segundos
mais rápido numa eventual queda.
412
5.2 - Update-source
 Ajustando o update-source nas sessões R1<->R4 e R1<->R5

AS-X-R1#conf t
 Ajustando o update-source nas sessões R2<->R4 e R2->R5
AS-X-R2#conf t
LAB 2-1-2 413

5.3 – Next-hop-self
 Estabelecidas as sessões iBGP e eBGP, vamos aos "novos"

problemas:

...
*> X.0.0.0 0.0.0.0 0 32768 i
*> 187.X.0.0/22 2.101.1.2 0 201 i

...
*> X.0.0.0 0.0.0.0 0 32768 i
 Notem que não estamos anunciando as redes recebidas

pelos meus DOWNSTREAMS, mas apenas o classe A do AS
local.
– Por que?
LAB 2-1-3 414
 O primeiro critério para o protocolo BGP anunciar algum prefixo é

que esse prefixo esteja válido na FIB.
AS-X-R1#sh ip bgp
...
*> X.0.0.0 0.0.0.0 0 32768 i
* i154.X.0.0.0 X.104.1.2 0 100 0 40X i
* i155.X.0.0.0 X.105.1.2 0 100 0 50X i
...
 O prefixo "X.0.0.0" está com o caractere ">", o que demonstra
que esse prefixo está de fato na FIB (best).
 Porém não é o que acontece com os prefixos recebidos dos
DOWNSTREAMS.
 Os prefixos 154.X.0.0 e 155.X.0.0 estão na RIB, mas não na FIB.
 Por que esses prefixos não estão na FIB?
LAB 2-1-3 415

 Vamos verificar detalhadamente o status de um desses prefixos

em R1...
AS-X-R1#sh ip bgp 154.X.0.0
Paths: (1 available, no best path)
40X
X.104.1.2 (inaccessible) from X.0.0.4 (X.0.0.4)
Origin IGP, metric 0, localpref 100, valid, internal, not synchronized
 Um problema é perceptível sem muito trabalho:
"X.104.1.2 (inaccessible)"
 Para que esse prefixo seja válido na FIB é necessário que o "next-
hop" correspondente também seja válido, o que não ocorre.
 Mas esse é apenas um dos problemas perceptíveis na saída do
último comando.
LAB 2-1-3 416
 Resolvendo o primeiro problema:

 Não é recomendável que as interfaces externas do AS participem do IGP
(OSPF), portanto vamos para outra solução.
 Vamos então utilizar o comando BGP "next-hop-self" que altera o next-hop
para o IP de neighbor.
AS-X-R1#conf t
AS-X-R1(config-router)#neighbor X.0.0.4 next-hop-self
AS-X-R2#conf t
LAB 2-1-2 417

 Continuando em R4 e R5...
AS-X-R4#conf t
AS-X-R5#conf t
 Vamos agora verificar as mudanças...
LAB 2-1-3 418

5.4 - BGP Synchronization
 Vamos detalhar novamente um dos prefixos em R1:

Paths: (1 available, no best path)
40X
X.0.0.4 (metric 129) from X.0.0.4 (X.0.0.4)
Origin IGP, metric 0, localpref 100, valid, internal, not synchronized
 Notem que o next-hop não se encontra mais inacessível, porém a

rota mostra uma outra mensagem: "NOT SYNCRONIZED".
 Isso acontece com rotas aprendidas por iBGP, uma vez que por
padrão o protocolo exige a sincronização da rota antes de
anunciá-la aos AS's externos.
 Nas versões e caixas mais novas o ”syncronize” vem desabilitado.
LAB 2-1-4 419

 Resolvendo o problema de maneira "duvidosa" em R1 e

R2...
AS-X-R1#conf t
AS-X-R1(config-router)#no synchronization
AS-X-R2#conf t
LAB 2-1-4 420

 Continuando em R4 e R5...
AS-X-R4#conf t
AS-X-R5#conf t
LAB 2-1-4 421

 Conferindo as mudanças em R1 e demais:
AS-X-R1#sh ip bgp
...
*> X.0.0.0 0.0.0.0 0 32768 i
*> 100.0.0.0 100.X.1.1 0 0 100 i
*>i14X.0.0.0 X.0.0.4 0 100 0 146 i
*>i15X.0.0.0 X.0.0.5 0 100 0 156 i
 Verificando o caractere ">" podemos ter certeza dessa vez

as rotas foram para FIB.
LAB 2-1-4 422

 Vamos agora ter certeza que os prefixos do meus

DOWNSTREAMS estão sendo anunciados aos UPSTREAMS:

100.X.1.1
40X
X.0.0.4 (metric 129) from X.0.0.4 (X.0.0.4)
Origin IGP, metric 0, localpref 100, valid, internal, best
 Bingo!! Estamos anunciando os prefixos de DOWNSTREAMS para

o AS 100.
 O mesmo vale para R2, R4 e R5, é só conferir.
LAB 2-1-4 423

 Agora entrem no Looking Glass e testem a conectividade IP
para os AS's clientes 40X e 50X
Telnet 123.123.123.1...
!--executem traceroute para os IPs dos seus respectivos downstreams

1 123.222.1.2 12 msec 16 msec 16 msec

2 222.222.1.2 [AS 222] 12 msec 40 msec 32 msec
3 222.200.1.2 [AS 222] 72 msec 56 msec 56 msec
4 200.200.2.2 [AS 200] 56 msec 68 msec 68 msec
5 200.2.2.2 [AS 200] 100 msec 84 msec 88 msec
6 * * *
7 * * *
8 * * *
 CONCLUSÕES: Se o "syncronization" existe, precisamos
compreender sua função antes de desabilitá-lo.
LAB 2-1-4 424
 Entendendo o "syncronization"...
 Uma proteção natural que o BGP implementa é exigir a

sincronização de uma rota aprendida por iBGP antes de
inseri-la na FIB.
 Quando um router recebe um prefixo de origem "internal"

através de iBGP esse não tem como saber se os routers
intermediários também conhecem rota para esse prefixo.
 Vamos entender melhor...
425
 Entendendo o ”syncronization”...
 R4 estabelece um iBGP diretamente com R1 e anuncia os

prefixos recebidos do AS 40X. O problema é que AS-X-R1
não tem como saber se R3 conhece rota para os prefixos
do AS 40X.
 O syncronization é um mecanismo de proteção que evita

loops de roteamento dentro do AS
 Vamos entender melhor o que aconteceu no LAB.
426
 AS 40X anuncia seus prefixos para R4...
427
 AS R4 anuncia para R1...
428
 AS R1 anuncia para o UPSTREAM AS 100...
429
 AS 100 anuncia para o AS 99...
430
 Caminho dos pacotes: Entram no AS 100...
431
 Caminho dos pacotes: em seguida no AS por R1...
432
 Caminho dos pacotes: agora complica um pouco, R1

conhece rota para 11X.0.0.0/8 através do next-hop
X.0.0.4 (R4), e esse next-hop é alcançável via R3
(X.X.1.2).
433
 Caminho dos pacotes: ”Ninguém avisou para R3” qualquer

coisa sobre um tal AS 11X, o que ele faz com um pacote
cujo destino não conhece? (rota padrão) O pacote é
devolvido para R1.
434
 Caminho dos pacotes: Mas R1 consulta novamente sua FIB,

e ”tem certeza” que o pacote deve mesmo ser entregue
para R3...
435
 Caminho dos pacotes: E o loop se repete até o fim do TTL do

pacote...
436
 Por isso precisamos ter certeza antes de "desabilitar" o

syncronization.
 Veremos 3 maneiras de resolver esse problema:
437
 Por isso precisamos ter certeza antes de "desabilitar" o

syncronization.
 Veremos 3 maneiras de resolver esse problema, a primeira
delas é com o syncronization HABILITADO e redistribuindo
rotas BGP através do IGP (OSPF nesse caso);
 A segunda maneira é desabilitando o syncronization e
estabelecendo FULL-MESH entre todos os routers do AS;
 A terceira (e melhor) é utilizando MPLS (sem BGP) nos
routers do backbone (nesse LAB apenas R3) e que
encaminham rotas aprendidas via BGP através de Labels.
Veremos essa no capítulo 8.1 (BGP através da nuvem
MPLS);
 Vamos à primeira!
438
 Distribuindo as rotas BGP através do meu IGP:
!--- primeiro vamos habilitar novamente o syncronization

AS-X-R1#conf t
!--- agora entrar na configuração do OSPF
AS-X-R1(config)#router ospf 1
AS-X-R1(config-router)#redistribute bgp X
!--- habilita a distribuição por OSPF de rotas aprendias por BGP
% Only classful networks will be redistributed
AS-X-R1#clear ip ospf process
!--- reinicia o processo OSPF
Reset ALL OSPF processes? [no]: yes
AS-X-R1#
!--- vamos repetir o mesmo processo para R2, R4 e R5
LAB 2-1-5 439


AS-X-R2#conf t
AS-X-R2#
LAB 2-1-5 440


AS-X-R4#conf t
AS-X-R4#
LAB 2-1-5 441


AS-X-R5#conf t
AS-X-R5#
LAB 2-1-5 442

 Agora vamos verificar em R1 as rotas recebidas do AS-40X
via R4:
AS-X-R1#sh ip bgp

…
*> 99.0.0.0 100.X.1.1 0 100 99 i
*> 100.0.0.0 100.X.1.1 0 0 100 i
*r>i154.X.0.0 X.0.0.4 0 100 0 14X i
*r>i155.X.0.0 X.0.0.5 0 100 0 15X i
*> 200.0.0.0 100.X.1.1 0 100 99 200 i
...
 Agora podemos ver pelo ">" que a rota para 154.X.0.0 está
na FIB.
 Outro detalhe é o "i" à esquerda identifica a rota como
"internal".
LAB 2-1-5 443
 Detalhando os prefixos do meu DOWNSTREAM:

BGP routing table entry for 14X.0.0.0/8, version 5
100.X.1.1
11X
X.0.0.4 (metric 129) from X.0.0.4 (X.0.0.4)
Origin IGP, metric 0, localpref 100, valid, internal, synchronized, best
 Temos agora uma rota SINCRONIZADA, VÁLIDA, e

ANUNCIADA para 100.X.1.1 (AS 100).
LAB 2-1-5 444
 Segunda maneira é desabilitando o syncronization, porém

alterando os BGP peers.
 Vamos refazer as configurações BGP estabelecendo R4<-

>R3 e R3<->R1.
 Dessa forma R3 vai conhecer a rota para os DOWSTREAMS e

UPSTREAMS.
445
 Mas antes vamos desconfigurar a redistribuição de prefixos

via OSPF em R1, R2, R4 e R5...
AS-X-R1#conf t
AS-X-R1(config-router)#no redistribute bgp X
AS-X-R1#
!--- vamos repetir o mesmo processo para R2, R4 e R5
LAB 2-1-6 446

 R2
AS-X-R2#conf t
AS-X-R2#
LAB 2-1-6 447

 R4
AS-X-R4#conf t
AS-X-R4#
LAB 2-1-6 448

 R5
AS-X-R5#conf t
AS-X-R5#
LAB 2-1-6 449

 Vamos alterar o esquema das sessões removendo todas as
sessões iBGP...
AS-X-R1(config-router)#no neighbor X.0.0.4
!--- R1
!--- R2
!--- R4
AS-X-R5(config-router)#no syncrhonization
LAB 2-1-6 450
 Restabelecendo as sessões BGP em R1

● Em seguida iBGP entre R1 e R3:
AS-X-R1#conf t
AS-X-R1(config-router)#neighbor X.0.0.3 description iBGP R3
!--- não vamos utilizar nenhum filtro de in-out para a sessão com R3
LAB 2-1-6 451

 Reestabelecendo as sessões BGP em R1

● Em seguida iBGP entre R2 e R3:
AS-X-R2#conf t
!--- não vamos utilizar nenhum filtro de in-out
LAB 2-1-6 452

 Configurando iBGP com R3
AS-X-R4#conf t
LAB 2-1-6 453

 Configurando iBGP com R3
AS-X-R5#conf t
LAB 2-1-6 454

 Restabelecendo as sessões iBGP em R3:

!--- iBGP com R1
!--- iBGP com R2
!--- iBGP com R4
!--- iBGP com R5
LAB 2-1-6 455

 Verificando as mudanças começando por R1
AS-X-R1#sh ip bgp

*>iX.0.0.0 X.0.0.3 0 100 0i
*> 100.0.0.0 100.X.1.1 0 0 100 i
*> 99.0.0.0 100.X.1.1 0 0 100 99 i
...
 Ainda não temos a rota anunciada pelo DOWNSTRASM AS
14X na FIB de R1, isso porque R3 não está anunciando!
 Por que isso acontece?
LAB 2-1-6 456

 BGP e o SPLIT HORIZON
 Desde o tempo do RIP, os protocolos do tipo vetor de

distância sabem que não há sentido em propagar uma
rota para a mesma interface de onde aprendeu, e com o
BGP é parecido.
 No iBGP é indispensável* que haja fullmesh de sessões BGP

(todos estabelecendo com todos) e sendo assim, um
router não anuncia por iBGP uma rota que foi aprendida
também por iBGP, pois entende que aquele router que me
enviou a rota já está enviando diretamente para todos os
routers do iBGP.
*há um mecanismo que dispensa essa necessidade 457
 Em resumo, um router não anuncia para outro router do

mesmo AS qualquer coisa que tenha aprendido também
via iBGP.
 Ou seja, R3 não vai anunciar para R1 as rotas aprendidas de

R4.
458
5.5
Route-Reflector
459
5.5 - Route-Reflector
 Em tese, de acordo com as regras do split horizon deveríamos

estabelecer as seguintes sessões BGP (full mesh):
R1<->R2, R1<->R3, R1<->R4, R1<->R5
R2<->R3, R2<->R4, R1<->R5
R3<->R4, R3<->R5
R4<->R5
Total=10
 O route-reflector basicamente dispensa a necessidade de iBGP
full-mesh, pois remove a restrição no repasse de rotas iBGP
para outro neighbor iBGP.
 É altamente recomendado quando o número de routers é maior
que 5:
*evita um número muito grande de sessões iBGP
460
 Nessa topologia de rede em particular, podemos optar por 3
modelos:
1- R1 como Route-Reflector estabelecendo com R2, R3, R4 e

R5 (4 sessões).
✗ Pontos críticos de falha: falha em R3 e/ou R1 e/ou link R3<-
>R1 = 3.
461

R5 (4 sessões).
✗ Pontos críticos de falha: falha em R3 e/ou R2 e/ou link R3<-
>R2 = 3.
462

R5 (4 sessões).
✗ Pontos críticos de falha: falha em R3= 1.
463
 Obviamente já optamos pela opção número 3

● Vamos acrescentar apenas a opção RR:
AS-X-R3#conf t
AS-X-R3(config-router)#neighbor X.0.0.1 route-reflector-client
!--- iBGP com R1
!--- iBGP com R2
!--- iBGP com R4
!--- iBGP com R5
LAB 2-1-7 464

 É importante deixar claro que diferentemente do que o

nome possa sugerir, "Route-reflector" não significa
"refletir a rota" e preservar o next-hop original, isso é uma
característica do próprio iBGP. Route-Reflector significa
anunciar via iBGP rotas aprendidas também por iBGP.
465
5.6
Peer Groups
466
5.6 - Peer Groups
 Em nossa topologia, ficamos diante de uma situação:
 R3 possui vários neighbors com configurações semelhantes,

exigindo configurações repetitivas e sujeitas à erros.
 O recurso "peer-group" me permite realizar um padrão para

os neighbors semelhantes diminuindo drasticamente a
quantidade de linhas de configuração e "show run".
467
5.6 - Peer Groups
 Vamos praticar reconfigurando R3 com peer-groups:
!--- Primeiro vamos resetar as config de BGP

AS-X-R3#conf t
!--- depois as configurações básicas
!--- Vamos declarar um peer-group chamado IBGP
AS-X-R3(config-router)#neighbor IBGP peer-group
AS-X-R3(config-router)#neighbor IBGP remote-as X
AS-X-R3(config-router)#neighbor IBGP update-source loopback 0
AS-X-R3(config-router)#neighbor IBGP soft-reconfiguration inbound
AS-X-R3(config-router)#neighbor IBGP route-reflector-client
!--- Vamos adicionar os neighbors que fazem parte desse grupo
AS-X-R3(config-router)#neighbor X.0.0.1 peer-group IBGP
LAB 2-1-8 468

5.6 - Peer Groups
 Com peer-group fica muito mais simples adicionar remover

configurações de neighbors para todo o grupo em apenas um
comando, por exemplo:
!--- apenas exemplo, não efetue essa configuração
router(config-router)#neighbor IBGP prefix-list FILTRO-GERAL-DE-ENTRADA in
router(config-router)#neighbor IBGP prefix-list FILTRO-GERAL-DE-SAIDA out
!--- apenas exemplo, não efetue essa configuração
 Todas as sessões BGP dentro do peer-group passariam pelos

mesmos filtros de entrada e de saída
!--- A mesma simplicidade acontece na hora de um "clear" (route refresh)

AS-X-R3#clear ip bgp peer-group IBGP soft
!--- mas vale lembrar que nada impede que seja efetuado um clear individual
AS-X-R3#clear ip bgp X.0.0.1 out
469
5.6 - Peer Groups
 Finalizando o LAB:
 Acessar o Looking Glass e verificar se esse alcança o AS do grupo
e todos os seus respectivos DOWNSTREAMS
Telnet 123.123.123.1 ...
LAB 2-1-8 470

5.7
Local Preference x Weight no

iBGP
471
5.7 - Local Preference x Weight no iBGP
 Características:
Weight:
✔ Proprietário Cisco (embora implementado por Mikrotik, Vyatta, Quagga, OpenBGPD)
✔ Primeiro critério na escolha de rotas (maior weight)
✔ Não é considerado um atributo e seu valor pode ser de 0 a 65535
✔ Os valores de weight não são transitivos (mesmo dentro do AS)
Local Preference:
✔ Conhecido em todas as implementações de BGP
✔ Segundo critério depois do weight (maior local pref)
✔ Seu valor padrão é 100 e pode variar de 0 a 4294967295
✔ Os valores alterados são propagados por todo o iBGP
472
 Como vimos nos labs anteriores, posso atribuir um valor de weight 10 no comando "neighbor
x.x.x.x weight 10" para todas as rotas recebidas, ou manualmente apenas para
determinados prefixos utilizando o route-map. Vamos alterar o weight apenas de um
determinado prefixo (99.0.0.0/8) e todos os seus sub-prefixos
AS-X-R1#conf t
AS-X-R1(config)#ip prefix-list BLOCOS-AS-123 permit 123.0.0.0/8 le 24
!--- adiciona o classe A e sub-redes 123.0.0.0 na prefix-list BLOCOS-AS-123
AS-X-R1(config-route-map)#match ip address prefix-list BLOCOS-AS-123
AS-X-R1(config-route-map)#set weight 10
!--- estabelece os prefixos da lista BLOCOS-AS-123 como condição para receber a ação permir
!--- e a modificação opcional que atribui um valor 10 de weight
AS-X-R1#clear ip bgp 100.X.1.1 soft
LAB 2-1-9 473

 Conferindo a modificação:
AS-X-R1#sh ip bgp
...
*> 123.0.0.0 100.X.1.1 0 10 100 111 55 123 i

*> 100.0.0.0 100.X.1.1 0 0 100 i
...
 Apenas os prefixos dentro de 123.0.0.0/8 receberam weight 10

 Verifiquem a mesma rota em R2, R3,R4 ou R5 o valor de weight será 0,
já que esse não é propagado através do iBGP
LAB 2-1-9 474

 Já com o local preference é diferente, o valor que configurarmos em

R1 permanecerá o mesmo em todos os routers do AS que
receberem esse prefixo através de iBGP
✗ OBS: Caso algum router aplique route-map que altere o local

preference do prefixo 123.0.0.0 ou de todos os prefixos
recebidos, esse valor é substituído pelo atual
475
 A maneira mais indicada de priorizar rotas dentro do iBGP é

utilizando o local preference
 O weight deve ser usado apenas em casos muito específicos onde

não haja a intenção de que os outros routers do AS escolham
essa mesma rota
476
 LAB:
 utilizando os recursos vistos no curso vamos configurar os
routers do AS de maneira que atenda todos os seguintes
requisitos:
✔ Todo o tráfego de saída (upload) deve utilizar o link do AS 100, exceto com destino ao AS 200
via R1
✔ Simulando que o link do AS 200 está sobrecarregado, o tráfego de entrada (download) do
DOWNSTREAM AS 50X (apenas) deve chegar pelo AS 100
LAB 2-1-9 477

 Todo o tráfego de saída (upload) deve utilizar o link do AS 100, exceto com destino ao AS 200 via
R1
 Configurações em R1
AS-X-R1(config)#no route-map AS-100-IN permit 20

LAB 2-1-9 478

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
479
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
480
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
481
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
482
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
ATENÇÃO!! 10X
483
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
ATENÇÃO!! 10X
484
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
R2 PRECISA USAR O LINK DIRETO 10X
485
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
R2 PRECISA USAR O LINK DIRETO 10X
486
R1
 Verificando status inicial em R4:
AS-X-R4#traceroute 123.123.123.1

1 X.X.4.1 16 msec 16 msec 16 msec

4 222.200.1.1 [AS 222] 48 msec 56 msec 56 msec
5 222.222.1.1 [AS 222] 88 msec 76 msec 76 msec
6 123.222.1.1 [AS 123] 76 msec * 88 msec
LAB 2-1-9 487

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
488
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
489
R1
 Testando rota para 123.123.123.1 novamente em R4 após configurações em R1

4 111.100.1.1 [AS 111] 80 msec 44 msec 64 msec
5 111.111.1.1 [AS 111] 100 msec 88 msec 80 msec
6 55.111.1.1 [AS 55] 88 msec 96 msec 96 msec
7 55.55.1.1 [AS 55] 128 msec 108 msec 120 msec
8 123.55.1.1 [AS 123] 120 msec * 120 msec
LAB 2-1-9 490

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
491
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
492
R1
 Para alcançar o AS 200 a rota escolhida não foi a rota correta...


4 111.100.1.1 [AS 111] 48 msec 68 msec 64 msec
5 111.111.1.1 [AS 111] 100 msec 80 msec 84 msec
6 55.111.1.1 [AS 55] 84 msec 112 msec 96 msec
7 55.55.1.1 [AS 55] 112 msec 116 msec 120 msec
8 123.55.1.1 [AS 123] 124 msec 120 msec 104 msec
9 123.222.1.2 [AS 123] 108 msec 116 msec 112 msec
10 222.222.1.2 [AS 222] 116 msec 120 msec 120 msec
11 222.200.1.2 [AS 222] 116 msec * 104 msec
LAB 2-1-9 493

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
494
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
495
R1
 Precisamos fazer ajustes em R2:
AS-X-R2(config)#ip as-path access-list 200 permit ^(200 ?)+$
AS-X-R2(config-route-map)#match as-path 200
LAB 2-1-9 496

R1
 Novamente em R4 o teste dessa vez foi bem sucedido!


3 200.X.2.1 [AS 200] 68 msec * 56 msec
LAB 2-1-9 497

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
498
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
499
R1
 Porém um dos requisitos não foi atendido, R2 alcança o AS 123 via R3->R1 e não pelo link direto
como deveria...


4 111.100.1.1 [AS 111] 48 msec 64 msec 68 msec
5 111.111.1.1 [AS 111] 96 msec 88 msec 84 msec
6 55.111.1.1 [AS 55] 88 msec 92 msec 100 msec
7 55.55.1.1 [AS 55] 128 msec 112 msec 116 msec
8 123.55.1.1 [AS 123] 124 msec * 132 msec
LAB 2-1-9 500

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
501
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
502
R1
 Para corrigir esse problema precisamos manipular um atributo mais forte que o local preference...
AS-X-R2#show ip bgp 123.0.0.0/8

3
100 111 55 123, (received & used) QUEREMOS ESSA
100.X.2.1 from 100.X.2.1 (100.0.0.100) ROTA COMO BEST

200 222 123, (received & used)
200.X.2.1 from 200.X.2.1 (200.0.0.100)
100 111 55 123, (received & used)
X.0.0.1 (metric 3) from X.0.0.3 (X.0.0.3)
Originator: X.0.0.1, Cluster list: X.0.0.3
LAB 2-1-9 503

R1
 Vamos utilizar o atributo Weight para que ele atue antes do local-preference...
AS-X-R2(config-router)#neighbor 100.X.2.1 weight 10
AS-X-R2#clear ip bgp 100.X.2.1
LAB 2-1-9 504

R1
 E agora realizar dois novos testes, um para o AS 123...


2 111.100.1.1 [AS 111] 16 msec 32 msec 36 msec
3 111.111.1.1 [AS 111] 68 msec 44 msec 52 msec
4 55.111.1.1 [AS 55] 60 msec 56 msec 52 msec
5 55.55.1.1 [AS 55] 92 msec 76 msec 76 msec
6 123.55.1.1 [AS 123] 100 msec * 108 msec
 SUCESSO!!
LAB 2-1-9 505

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
506
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
507
R1
 … E outro para o AS 200, afinal se o destino for o AS 200 precisa usar o link direto...


2 111.100.1.1 [AS 111] 12 msec 24 msec 28 msec
3 111.111.1.1 [AS 111] 52 msec 52 msec 44 msec
4 55.111.1.1 [AS 55] 48 msec 52 msec 56 msec
5 55.55.1.1 [AS 55] 88 msec 72 msec 76 msec
6 123.55.1.1 [AS 123] 108 msec 96 msec 100 msec
7 123.222.1.2 [AS 123] 132 msec 124 msec 132 msec
8 222.222.1.2 [AS 222] 136 msec 136 msec 140 msec
9 222.200.1.2 [AS 222] 140 msec * 152 msec
 A rota escolhida não foi a correta!
LAB 2-1-9 508

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
509
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
510
R1
 E o ajuste final...
AS-X-R2(config-route-map)#set weight 11
 De maneira que o Route-map apareça assim:

AS-X-R2#sh run
...
!
route-map AS-200-IN permit 5
match as-path 200
set weight 11
!
…
AS-X-R2#clear ip bgp 200.1.2.1 soft
LAB 2-1-9 511

R1
 Vamos ver o resultado no comando show...
AS-X-R2#show ip bgp 200.0.0.0/8

Flag: 0x820
3 5
100 111 55 123 222 200
100.X.2.1 from 100.X.2.1 (100.0.0.100)
Origin IGP, localpref 100, weight 10, valid, external
100 111 55 123 222 200, (received-only)
100.X.2.1 from 100.X.2.1 (100.0.0.100)
200
200.X.2.1 from 200.X.2.1 (200.0.0.100)
Origin IGP, metric 0, localpref 106, weight 11, valid, external, best
200, (received-only)
200.X.2.1 from 200.X.2.1 (200.0.0.100)
Origin IGP, metric 0, localpref 100, valid, external
LAB 2-1-9 512

R1
 E um traceroute para finalizar...

1 200.X.2.1 [AS 200] 8 msec * 8 msec
LAB 2-1-9 513

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
514
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
515
 Simulando que o link do AS 200 está sobrecarregado, o tráfego de entrada (download) do

1 123.222.1.2 16 msec 12 msec 20 msec

2 222.222.1.2 [AS 222] 12 msec 36 msec 40 msec
3 222.200.1.2 [AS 222] 68 msec 44 msec 48 msec
4 200.1.1.2 [AS 200] 80 msec 76 msec 72 msec
5 X.X.1.2 [AS 1] 80 msec 96 msec 96 msec
LAB 2-1-9 516

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
517
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
518

Paths: (2 available, best #1, table Default-IP-
Routing-Table)
2
222 200 X 50X
123.222.1.2 from 123.222.1.2 (222.222.1.1)
55 111 100 X 50X
123.55.1.2 from 123.55.1.2 (123.55.1.2)
LAB 2-1-9 519

 Vamos corrigir isso em R1 e R2 nos filtros de saída com o AS 200
 R1
AS-X-R1(config-route-map)#set as-path prepend X X X X
AS-X-R1#clear ip bgp 200.X.1.1 out
LAB 2-1-9 520

 Vamos corrigir isso em R1 e R2 nos filtros de saída com o AS 200
 R2
AS-X-R2(config-route-map)#set as-path prepend X X X X
LAB 2-1-9 521

 Agora vamos verificar a mudança no AS 123 com o comando show...

Flag: 0x820
1
55 111 100 X 50X
123.55.1.2 from 123.55.1.2 (123.55.1.2)
LAB 2-1-9 522

 Em seguida com traceroute...

1 123.55.1.2 16 msec 16 msec 16 msec

2 55.55.1.2 [AS 55] 16 msec 32 msec 40 msec
3 55.111.1.2 [AS 55] 72 msec 44 msec 44 msec
4 111.111.1.2 [AS 111] 56 msec 60 msec 68 msec
5 111.100.1.2 [AS 111] 92 msec 88 msec 88 msec
LAB 2-1-9 523

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
524
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
525
 Pela quantidade de prepends, até mesmo o AS 222 alcnça o AS 50X pelo link do AS 100...

Flag: 0x820
2
123 55 111 100 X 50X
123.222.1.1 (metric 2) from 222.222.1.1 (222.222.1.1)
200 X X X X X 50X
222.200.1.2 from 222.200.1.2 (200.0.0.100)
LAB 2-1-9 526

 Pela quantidade de prepends, até mesmo o AS 222 alcnça o AS 50X pelo link do AS 100...

1 222.222.1.1 12 msec 20 msec 16 msec

2 123.222.1.1 [AS 123] 16 msec 32 msec 36 msec
3 123.55.1.2 [AS 123] 68 msec 52 msec 56 msec
4 55.55.1.2 [AS 55] 84 msec 76 msec 68 msec
5 55.111.1.2 [AS 55] 88 msec 96 msec 96 msec
6 111.111.1.2 [AS 111] 128 msec 120 msec 116 msec
7 111.100.1.2 [AS 111] 108 msec 124 msec 128 msec
LAB 2-1-9 527

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
528
50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
529
OK, MAS E SE EU QUISER QUE

O TRÁFEGO CHEGUE NO MEU
AS VIA R2 E NÃO VIA R1 COMO
ESTÁ ACONTECENDO AGORA???
LAB 2-1-9 530

LAB 2-1-9 531

AS-X-R1#show run
Building configuration...
Current configuration : 5482 bytes

...
!
route-map AS-100-OUT permit 40
match ip address prefix-list BLOCOS-AS-50X
!
...
LAB 2-1-9 532

AS-X-R1(config-route-map)#set metric 10
LAB 2-1-9 533

AS-X-R1#show run
Building configuration...
Current configuration : 5482 bytes

...
set metric 10
!
...
LAB 2-1-9 534

AS-123-R1#traceroute 155.X.0.1

1 123.55.1.2 20 msec 16 msec 16 msec

2 55.55.1.2 [AS 55] 12 msec 32 msec 36 msec
3 55.111.1.2 [AS 55] 68 msec 48 msec 44 msec
4 111.111.1.2 [AS 111] 48 msec 68 msec 64 msec
5 111.100.1.2 [AS 111] 100 msec 84 msec 88 msec
LAB 2-1-9 535

50Z
111
55
100 R2 R5 50X
AS-X
123
R3
610XX
222 200
R1 R4 40X
10X
536
537
DESFAZENDO A ENGENHARIA DE
TRRÁFEGO II
#############R1###########################
AS-X-R1(config-route-map)#no set local-preference 105
AS-X-R1(config-route-map)#no set metric 10
AS-X-R1(config-route-map)#no set as-path prepend X X X X
#############R2###########################
AS-X-R2(config)#no route-map AS-200-IN permit 5

AS-X-R2(config-route-map)#no set as-path prepend
AS-X-R2(config-router)#no neighbor 100.X.2.1 weight 10
538
5.8
PERGUNTAS?
539
6.0
BGP Communities
540
6.0
BGP Communities
6. BGP Communities
• 6.1 Communities Padrão

• 6.2 Communities Numéricas
• 6.3 Identificando e tratando rotas de peers específicos
• 6.4 Manipulando trâsito (nacional/internacional) com communities
• 6.5 Engenharia de Tráfego III
541
6.1
Communities Padrão
542
6.1 – Communities Padrão
 Communities são atributos que são preservados em

anúncios entre AS's externos e internos.
 São um tipo de carimbo inserido nos updates em forma de

string.
 Uma community é um atributo opcional, e sendo assim nada

obriga que os fabricantes implementem no BGP de suas
caixas, ou mesmo que um AS replique para seus peers o
mesmo valor de community recebido por um de seus
clientes.
543
 Os modelos mais novos suportam o "novo formato"

usualmente utilizado como ASN:comunity, por exemplo:
28135:110.
 Porém há algumas communities padronizadas pela RFC

1997 e são padrão nos routers Cisco:
– INTERNET
– NO-EXPORT
– NO-ADVERTISE
– LOCAL-AS
– NO-ADVERTISE-SUBCONFED
544
 NO-EXPORT por padrão faz o router receptor exportar o

prefixo para neighbors iBGP, mas não para eBGP. É útil
quando faço anúncios mais específicos para a operadora
A e menos específicos para operadora B. Normalmente, a
operadora B precisaria passar pela operadora A para
chegar ao prefixo "específico" mesmo estabelecendo BGP
diretamente com meu AS.
Enviando o mesmo bloco específico, com a community NO-
EXPORT à operadora A, essa passaria a me alcançar
diretamente, ao mesmo tempo que não exportaria esses
prefixos.
545
 NO-ADVERTISE por padrão faz o router receptor não

exportar esse prefixo para nenhum neighbor, seja ele
eBGP ou iBGP.
546
 NO-ADVERTISE-SUBCONFED usada para evitar que o prefixo

seja exportado para AS's confederados.
547
 LOCAL-AS usada para evitar que os prefixos marcados

sejam exportados para fora do AS ou confederação,
geralmente usado em filtros de entrada.
548
 INTERNET na prática é a community padrão para anúncios

externos, é o mesmo que não haver nenhuma.
549
 LAB 1: Antes de começar remover todas as configurações do

laboratório anterior
AS-X-R1#conf t
AS-X-R1(config-route-map)#no set as-path prepend X X
550
 LAB 1: Antes de começar remover todas as configurações do

laboratório anterior
AS-X-R2#conf t
AS-X-R2(config-route-map)#no set as-path prepend X X
551
 Antes de iniciar os LABs desse capítulo é obrigatório

habilitar suporte ao envio de commuinities em
TODOS os neighbors.
 Em seguida habilitar o formato novo formato xxx:yyy para o
tratamento de communities:
router(config)#ip bgp-community new-format

router(config)#router bgp X
router(config-router)#neighbor A.B.C.D send-community both
router(config-router)#exit
LAB 2-2-1 552


TODOS os neighbors.

LAB 2-2-1 553


TODOS os neighbors.

LAB 2-2-1 554


TODOS os neighbors.

LAB 2-2-1 555


TODOS os neighbors.

LAB 2-2-1 556

 LAB 1: Anunciar os prefixos de um dos AS's clientes com a

community NO-EXPORT para dentro do AS do grupo:
(...)
[edit]
set policy-options policy-statement AS-X-OUT term 1 then community set no-export
set policy-options community no-export members no-export
commit
 Verifiquem nos routers R1 e R2 se os prefixos marcados

como "NO-EXPORT" estão sendo anunciados para os AS's
100 e 200.
LAB 2-2-1 557
juniper@AS-40X-R1# run show route advertising-protocol bgp X.104.1.1 detail
inet.0: 60 destinations, 60 routes (60 active, 0 holddown, 0 hidden)

* 154.X.0.0/16 (1 entry, 1 announced)
BGP group eBGP-upstream-AS-X type External
Nexthop: Self
AS path: [40X] I
Communities: no-export
LAB 2-2-1 558

 LAB 2 :
✔ Utilizar communities PADRÃO e fazer com que o
DOWNLOAD dos AS's 40X e 50X cheguem pelo link do
AS 100 quando a origem for o AS 123 (internet).
✔ Os routers do AS 200 deverão alcançar os DOWNSTREAMS
do grupo pelo link direto sem ter que ”dar a volta” pelo
AS 123.
LAB 2-2-1 559

 LAB 2 :

AS-X-R1(config-route-map)#set community no-export
LAB 2-2-1 560

 LAB 2 :

LAB 2-2-1 561

6.2
Communities Numéricas
562
6.2 - Communities Numéricas
 É muito pequena a quantidade de communities padrão,

podemos fazer pouquíssimas coisas com elas.
 Porém há uma grande quantidade communities numéricas

que podem ser utilizadas.
563
 É importante saber que essas communities numéricas por

padrão não influenciam em nada no tratamento das rotas.
 É preciso uma configuração prévia ação para cada

community.
564
 Também não há nenhum padrão para essas ações (pelo

menos nenhum padrão RFC).
 Entretanto muitos AS's implementaram padrões

extremamente criativos e funcionais.
565
 O conhecimento desses padrões é uma ferramenta chave

para resolver rapidamente incidentes do dia a dia.
 Vamos ver nos próximos slides uma série de communities

numéricas adotadas por algumas operadoras.
 Mas antes vamos habilitar o suporte ao novo formato...
router#conf t
566
6.3
Identificando e Tratando
Rotas de Peers Específicos
567
6.3 - Identificando e Tratando Rotas de
Peers Específicos
 Quando utilizamos o comando:
Router(config-route-map)#set community xxx:xxx
 Estamos substituindo todas as communities que haviam nesse

prefixo.
 Muitas vezes, é interessante adicionar mais de uma community
em "pontos diferentes".
Ex: Recebo prefixos dos meus downstreams e quero inserir uma
community 123:123 para controle interno, utilizando o meio
convencional, eu acabaria substituindo uma eventual
community que meu cliente utilizou para interagir com um
outro AS externo.
 O que fazer?
568
Peers Específicos
 Com o comando "additive" qualquer community existente é
preservada:
AS-X-R4(config-route-map)#set community 123:123 additive
✗ OBS: Digitar o comando "set community" tem efeito "cumulativo"
exemplo: se digitarmos a seguinte sequência de comandos:
router#conf t
router(config)#route-map teste permit 10
router(config-route-map)#set community 123:123
router(config-route-map)#end
router#
router#conf t
569
Peers Específicos
 Todas as communities digitadas serão ACUMULADAS:

router#sh running-config | begin route-map teste
route-map teste permit 10
set community 111:222 123:123 333:214 555:82
!
...
 Lembrem que o "additive" não tem a ver com esse fato, mas
sim com fazer com que as communities inseridas com
"additive" sejam "somadas" às communities que já
estavam taggeadas no(s) prefixo(s).
570
Peers Específicos
 Sem o comando "additive", qualquer community existente é

substituída.
 Sempre utilizem ”additive” na hora de colocar communities

em rotas recebidas de DOWNSTREAMS.
571
Peers Específicos
 LAB – Implementando políticas anúncio baseadas em

Community-list
✔ Estabelecer uma community (X:20) numérica para identificar que o prefixo foi
recebido de um cliente de trânsito:
✔ Aplicar um “set community X:20” nos filtros de entrada de todos os clientes
✔ Mudar os filtros da saida de UPSTREAMS para filtros baseados apenas em
community
572
Peers Específicos
 Inserindo a community X:20 para todas

as rotas recebidas do cliente 1 em R4
AS-X-R4#conf t
AS-X-R5(config)#ip bgp-community new-format
AS-X-R4(config-router)#no neighbor X.104.1.2 prefix-list BLOCOS-AS-40X in
!--- Desconfigura o filtro de entrada baseado em prefix-list
AS-X-R4(config-router)#neighbor X.104.1.2 route-map AS-40X-IN in
!--- Configura um filtro de entrada baseado em route-map
AS-X-R4(config-route-map)#set community X:20 additive
LAB 2-2-2 573

Peers Específicos

AS-3-R4# show ip bgp 154.X.0.0

Flag: 0x820
3
40X
X.104.1.2 from X.104.1.2 (154.X.0.1)
Community: X:20
403, (received-only)
X.104.1.2 from X.104.1.2 (154.X.0.1)
LAB 2-2-2 574

Peers Específicos

AS-X-R5#conf t
AS-X-R5(config)#ip bgp-community new-format
AS-X-R5(config-router)#no neighbor X.105.1.2 prefix-list BLOCOS-AS-50X in
!--- Desconfigura o filtro de entrada baseado em prefix-list
AS-X-R5(config-router)#neighbor X.105.1.2 route-map AS-50X-IN in
!--- Configura um filtro de entrada baseado em route-map
LAB 2-2-2 575

 LAB 2 :
AS-X-R1(config)#route-map AS-200-OUT permit 20 desconfigurar

AS-X-R1(config-route-map)#no set community no-export
R1
LAB 2-2-1 576

R2
 LAB 2 :
AS-X-R2(config)#route-map AS-200-OUT permit 20 desconfigurar

LAB 2-2-1 577

Peers Específicos
 Mesma configuração em R2...
AS-X-R1(config)#ip community-list standard CLIENTES permit X:20

AS-X-R1(config-route-map)#match community CLIENTES
AS-X-R1(config)#route-map AS-100-OUT permit 15 R1
AS-X-R2#conf t
AS-X-R2(config)#ip community-list standard CLIENTES permit X:20
!--- Cria uma community-list e adiciona a community X:20 nessa lista R2
*Com apenas 2 route-maps anunciarmos todos os clientes, mesmo que fossem dezenas
LAB 2-2-2 578
Peers Específicos
 Agora observem a configuração atual dos filtros de saída de R1
AS-X-R1#sh running-config | begin AS-100-OUT  Temos além do route-map “permit 10” (que
route-map AS-100-OUT permit 10 permite anúncio dos prefixos “locais”) mais dois,
match ip address prefix-list MEUS-BLOCOS
!
que permitem o anúncio de cada um dos
route-map AS-100-OUT permit 20 clientes.
!
 Após a marcação da community em R4 e R5, é
match ip address prefix-list BLOCOS-AS-40X possível fazer um route-map para anunciar
! todos os prefixos de clientes de transito que
...
foram anteriormente marcados com X:20
*Com apenas 2 route-maps anunciarmos todos os clientes, mesmo que fossem dezenas
LAB 2-2-2 579
Peers Específicos
AS-X-R1(config)#no route-map AS-200-OUT permit 20

AS-X-R1(config)#no route-map AS-100-OUT permit 20 R1

AS-X-R2#conf t
R2
Limpando os route-maps que se tornaram desnecessários

LAB 2-2-2 580
6.4
Manipulando Trânsito
(Nacional/Internacional) com
Communities
581
6.4 – Manipulando Trânsito
(Nacional/Internacional) com Communities
 Brasil Telecom
8167:90 Set Local Preference 90
* (default é Local Preference 200)
8167:3xy controle de anúncios
x: ação { 0 = não anuncia, 1,2,3 = insere x prepends)

y: peerings { 0=demais peerings, 1=internacionais, 2=Embratel,
3=Intelig, 4=Telemar, 5=Telefônica }
(exemplo: 312 = muda para 1 prepend o anúncio para a Embratel)
* (default é anunciar sem prepends para todos os peerings)
8167:555 => não exporta fora da Brasil Telecom.

8167:557 => não anuncia para sites internacionais.
8167:666 => serão injetados no BlackHole da Brasil Telecom.

8167:777 => somente anuncia para clientes da Brasil Telecom.
582
 Embratel
4230:120 - Local Preference - marcar a rota como localpreference 120

4230:10000 - Blackhole - bloqueia todo o tráfego para a rede/endereco
4230:10002 - Blackhole - filtra o tráfego internacional nos provedores
que proveem alguma especie de blackhole.
4230:10004 - Blackhole - filtra nos roteadores da Embratel nos EUA o
trafego destinado a rede/endereco anunciado
583
 GVT
Bloqueia anuncio Internacional AS:1

Bloqueia anuncio Nacional AS:2
Bloqueia anuncio Clientes GVT AS:3
Bloqueia anuncio Peering AS:4
Bloqueia anuncio PTT AS:6
Aonde, AS, deve ser o seu AS, exemplo: 1234:1
OBS: Quem tem AS de 32 bits não precisa se preocupar. Segundo a

GVT o número da esquerda pode ser qualquer coisa, o que importa é
o que vem na direita.
584
 Global Crossing
3549:100 - set local preference 100

3549:600 - Deny inter-continental export of tagged prefix [iBGP].

3549:666 - Deny inter-as export of tagged prefix (carry on AS 3549 only) [eBGP]
585
 Uma série de communities complexas possibilitam o
tratamento do prepend para cada um dos peers da GLBX
3549:8...
ASN Peer No Export Prepend+1 Prepend+2 Prepend+3
209 Qwest 8010 8011 8012 8013

701 MCI 8030 8031 8032 8033
1239 Sprint 8060 8061 8062 8063
1299 TeliaSonera 8250 8251 8252 8253
1668 AOL 8070 8071 8072 8073
2497 JPNIC 8080 8081 8082 8083
2516 KDDI 8100 8101 8102 8103
2914 NTT Verio 8120 8121 8122 8123
3257 Tiscali 8240 8241 8242 8243
3300 InfoNet Europe 8130 8131 8132 8133
3303 Swisscom 8140 8141 8142 8143
3320 T-Systems/DTAG 8150 8151 8152 8153
3356 Level 3 8160 8161 8162 8163
3561 Savvis 8170 8171 8172 8173
4134 ChinaNet 8230 8231 8232 8233
5511 OpenTransit 8190 8191 8192 8193
6461 AboveNet 8200 8201 8202 8203
6453 Teleglobe 8210 8211 8212 8213
7018 AT&T (US) 8220 8221 8222 8223
7738 Telemar 8290 8291 8292 8293
586
 Um cliente com o AS 4111 envia um prefixo com a
community "3549:8011 3549:8033 3549:8190".
 O prefixo com essa marca será anunciado da seguinte forma

para os peers GLBX:
Qwest (AS 209) receberá o prefixo com o AS PATH: "3549 3549 4111"
➔
MCI (AS 701) receberá o prefixo com o AS PATH: "3549 3549 3549 3549 4111"
➔
OpenTransit (AS 5511) não receberá o prefixo

➔
todos os outros receberão o prefixo normalmente: "3549 4111"

➔
587
 Intelig
17379:23004 - Community NO-EXPORT-INTERNACIONAL - Não anuncia para peers

Internacionais.
17379:23005 - Community NO-EXPORT-NACIONAL - Não anuncia para peers
Nacionais.
No-export ? A rota não será anunciada para nenhum peer eBGP da Intelig.
17379:60 = set local-preference 60
Todo anuncio feito, sem a aplicação de communities tem por default o

valor 100 de local Preference.
588
 CTBC e outras
http://drpeering.net/white-papers/Ecosystems/Evolution-of-the-U.S.-Peering-
Ecosystem.html
589
6.5
Engenharia de Tráfego III
590
6.5 - Engenharia de Tráfego III
 LAB 2: Considerando as políticas de community para o AS

200:

 A partir dos AS's clientes, utilizar as communities 200:xxx
para alterar o local preference dentro do AS 200, em
seguida observar que quando o mesmo é forçado a mudar
o local preference para menos de 100, automaticamente
começa a ”dar a volta” pelo AS 123, pois acaba
escolhendo rotas do AS 123 (local preference 100
padrão).
LAB 2-2-3 591

 Solução LAB 2:
(...)
[edit]
del policy-options policy-statement AS-X-OUT then community set no-export
commit
LAB 2-2-3 592

 Solução LAB 2:
!--- apagando o RM do lab anterior

vyatta@AS-50X-R1#
set policy route-map AS-X-OUT rule 10 action permit
set policy route-map AS-X-OUT rule 10 set community 222:90
set policy route-map AS-X-OUT rule 10 match ip address prefix-list MEUS-BLOCOS
delete protocols bgp 50X neighbor X.105.1.1 prefix-list export MEUS-BLOCOS
set protocols bgp 50X neighbor X.105.1.1 route-map export AS-X-OUT
LAB 2-2-4 593

6.5
PERGUNTAS?
594
7.0
Filtros Avançados
para Um AS de Trânsito
O trabalho Curso de BGP Design com Roteadores Cisco de Rinaldo Vaz foi licenciado com
uma Licença Creative Commons - Atribuição 3.0 Não Adaptada.
Podem estar disponíveis autorizações adicionais ao âmbito desta licença em
rinaldopvaz@gmail.com.
595
7.0
Filtros Avançados
para Um AS de
Trânsito
7. Filtros avançados para um AS de trânsito
• 7.1 Manipulando rotas de múltiplos PTTs

• 7.2 DOWNSTREAMS com multihoming
• 7.3 AS de trânsito no PTT – parte I
• 7.4 Configurando um trasporte Lan2lan com xconnect/L2TP
• 7.5 AS de trânsito no PTT – parte II
596
7.1
Manipulando Rotas com

Múltiplos PTTs
597
7.1 – Manipulando Rotas com Múltiplos Ptts
 Em alguns casos clientes de trânsito solicitam o recebimento

apenas de rotas do PTT-SP, por exemplo.
 Como filtrar e enviar um anúncio assim?
598
 Uma maneira simples é marcar uma community específica para

rotas recebidas:
AS-X-R1#conf t
AS-X-R1(config)#route-map PTT-SP-IN permit 999
...
 Esse comando adiciona a community X:1111 e preserva todas

que existirem.
599
 Se meu AS participa de mais de um PTT posso filtrar rotas
de ambos e exportar para o meu cliente:
AS-X-R2#conf t
AS-X-R2(config)#route-map PTT-RJ-IN permit 999
 Dado o cenário, vamos ver quais seriam os filtros que

enviariam para o cliente apenas rotas recebidas do PTT-
Rio de Janeiro e PTT-São Paulo:
AS-X-R1(config)#ip community-list 70 permit X:1111
AS-X-R1(config)#ip community-list 70 permit X:2222
AS-X-R1(config)#route-map AS-10X-OUT permit 10
AS-X-R1(config-route-map)#match community 70
AS-X-R1(config)router bgp X
AS-X-R1(config-router)#no neighbor X.101.1.2 filter-list 10 out
AS-X-R1(config-router)#neighbor X.101.1.2 route-map AS-10X-OUT out
AS-X-R1#clear ip bgp X.101.1.2 out
600
7.2
Downstreams com
Multihoming
601
7.2 – Downtreams com Multihoming
AS-X-R1(config)#no route-map AS-100-OUT
602
603
 Todos esses route-maps podem deixar a configuração um

pouco maior, porém vai permitir que os ”donos dos AS's”
sejam facilmente identificados no ”show run” além de
tornar muito fácil de escalar.
 Os clientes de trânsito AS 40X e 50X vão passar a prover
trânsito IP para outros 2 AS's respectivamente:
AS-40X => ASN 6110X CIDR 161.X.0.0/22

AS-50X => ASN 6110Z CIDR 161.Z.0.0/22
604
40X-R1
AS-40X-R1
LAB 2-1-1 605

downstream: AS 611XX em AS-40X-R1:
[edit]
juniper@AS-40X-R1#
set protocols bgp group eBGP-downstream-AS-611XX type external 40X-R1
set protocols bgp group eBGP-downstream-AS-611XX import AS-611XX-IN
set protocols bgp group eBGP-downstream-AS-611XX peer-as 611XX
set protocols bgp group eBGP-downstream-AS-611XX neighbor 154.X.100.2
set policy-options policy-statement AS-611XX-IN term 1 from route-filter 161.X.0.0/22 prefix-length-range /22-/24
set policy-options policy-statement AS-611XX-IN term 1 then accept
set policy-options policy-statement AS-611XX-IN then reject
set policy-options policy-statement AS-X-OUT term 2 from route-filter 161.X.0.0/22 prefix-length-range /22-/24
set policy-options policy-statement AS-X-OUT term 2 then accept
commit complete
[edit]
juniper@AS-40X-R1#
LAB 2-1-1 606

no Quagga a partir do Juniper...
juniper@AS-40X-R1>telnet 154.X.100.2
Trying 154.X.100.2 ... Open
Ubuntu 14.10
AS-611XX-R1 login: routerpc
Password: 123456
$
$ telnet 127.0.0.1 bgpd
Trying 127.0.0.1...
Hello, this is Quagga (version 0.99.23).

Copyright 1996-2005 Kunihiro Ishiguro, et al.
Password: 123456
AS-611XX-R1>
LAB 2-1-1 607

 Configurando o Quagga
AS-611XX-R1#conf t
AS-611XX-R1(config)# ip prefix-list ANUNCIOS-PARA-AS-40X permit 161.X.0.0/23
AS-611XX-R1(config)# ip prefix-list ANUNCIOS-PARA-AS-40X permit 161.X.0.0/22
AS-611XX-R1(config)# ip prefix-list ANUNCIOS-PARA-AS-50Y permit 161.X.2.0/23
AS-611XX-R1(config)# ip prefix-list ANUNCIOS-PARA-AS-50Y permit 161.X.0.0/22
AS-611XX-R1(config)# router bgp 611XX
AS-611XX-R1(config-router)# bgp router-id 161.X.0.1
AS-611XX-R1(config-router)# network 161.X.0.0/22
AS-611XX-R1(config-router)# neighbor 154.X.100.1 remote-as 40X
AS-611XX-R1(config-router)# neighbor 154.X.100.1 description eBGP com as 40X
AS-611XX-R1(config-router)# neighbor 154.X.100.1 soft-reconfiguration inbound
AS-611XX-R1(config-router)# neighbor 154.X.100.1 prefix-list ANUNCIOS-PARA-AS-40X out
AS-611XX-R1(config-router)# neighbor 155.Y.100.1 remote-as 50Y
AS-611XX-R1(config-router)# neighbor 155.Y.100.1 description eBGP com as 50Y
AS-611XX-R1(config-router)# neighbor 155.Y.100.1 soft-reconfiguration inbound
AS-611XX-R1(config-router)# neighbor 155.Y.100.1 prefix-list ANUNCIOS-PARA-AS-50Y out
AS-611XX-R1(config-router)#end
AS-611XX-R1# clear ip bgp *
LAB 2-1-1 608

R1
AS-50X-R1
LAB 2-1-1 609


downstream: AS6110Z em AS-50X-R1:
[edit]
vyatta@AS-50X-R1#
set protocols bgp 50X neighbor 155.X.100.2 remote-as 6110Z
set protocols bgp 50X neighbor 155.X.100.2 prefix-list import BLOCOS-AS-6110Z
set protocols bgp 50X neighbor 155.X.100.2 soft-reconfiguration inbound
set policy prefix-list BLOCOS-AS-6110Z rule 10 prefix 161.Z.0.0/22
set policy prefix-list BLOCOS-AS-6110Z rule 10 le 24
set policy prefix-list BLOCOS-AS-6110Z rule 10 action permit
set policy prefix-list MEUS-BLOCOS rule 20 prefix 161.Z.0.0/22
set policy prefix-list MEUS-BLOCOS rule 20 le 24
set policy prefix-list MEUS-BLOCOS rule 20 action permit
vyatta@AS-50X-R1# commit
[edit]
vyatta@AS-50X-R1#
LAB 2-1-1 610

R4
AS-X-R4
LAB 2-1-1 611


AS-X-R4#conf t R4
AS-X-R4#clear ip bgp X.104.1.2 in
LAB 2-1-1 612

R5
AS-X-R5
LAB 2-1-1 613


AS-X-R5#conf t R5
AS-X-R5(config)#ip prefix-list BLOCOS-AS-50X permit 161.Z.0.0/22 le 24
AS-X-R5(config)#exit
AS-X-R5#clear ip bgp X.105.1.2 in
LAB 2-1-1 614

R1
AS-X-R1
LAB 2-1-1 615

 Liberando os prefixos...
AS-X-R1#conf t R1
AS-X-R1(config)#exit
AS-X-R1#clear ip bgp * out
LAB 2-1-1 616

R2
AS-X-R2
LAB 2-1-1 617

 Liberando os prefixos...
AS-X-R2#conf t R2
AS-X-R2#clear ip bgp * out
LAB 2-1-1 618

 Os filtros baseados apenas em prefixos nos trazem um

problema:
 Como AS de trânsito, geralmente temos vários peers, e caso

um dos nossos clientes também tenha outros peers, um
filtro baseado unicamente em prefixos pode acabar
fazendo o meu AS exportar prefixos errados.
 Por exemplo, sou o AS X, compro trânsito do AS 100. Meu

cliente é o AS 20, que por sua vez compra trânsito com o
AS 200, que também é meu trânsito
619
 Caso o AS 20 anunciasse um bloco específico para cada AS

(X e 200), essa seria minha FIB:
router# sh ip bgp 20.0.0.0/20 longer-prefixes

...
*>i20.0.8.0/21 200.100.1.1 0 200 20 i
*>i20.0.0.0/21 100.20.1.2 300 10 20 i
*>i20.0.0.0/20 100.20.1.2 300 10 20 i
* 200.100.1.1 0 200 20 i
...
 Percebam que por ser válido na FIB, o prefixo 20.0.8.0/21

seria exportado para todos os peers externos (menos para
o AS 200 de onde "aprendemos") começando pelo AS
100.
620
 Precisamos adicionar mais uma condição de match além do

prefix list com expressões regulares.
 Esse é o route-map padrão que já conhecemos:
router(config)#ip prefix-list BLOCOS-AS-20-ACL33 permit 20.0.0.0/8 le 24
router(config)#route-map ANUNCIAR-AS-XXX permit 10

router(config-route-map)#match ip address prefix-list BLOCOS-AS-20-ACL33
!--- Adicionamos a seguinte acl:

router(config)#ip as-path access-list 33 permit ^20(_20)*$
!--- apenas se a rota tiver sido ORIGINADA pelo AS 20
!--- voltamos no mesmo route-map

router(config)#route-map ANUNCIAR-AS-XXX permit 10
!--- e adicionamos a condição
621
 A nomenclatura da prefix-list com final (ACL-33) é para facilitar,

pois
indica o número da ACL de as-path correspondente ao cliente.
 Nos routers Cisco não há possibilidade de nomear uma ACL de as-
path, podemos apenas utilizar apenas um número.
 Para quem usa Quagga é possível atribuir um nome para a ACL
de as-path e community lists o que deixa tudo ainda mais fácil:
router-quagga(config)#ip prefix-list BLOCOS-AS-20 permit 20.0.0.0/8 le 24
router-quagga(config)#ip as-path access-list PATH-AS-20 permit ^(20|(20_{0,1}){1,8})$
!--- Essa expressão limita em no máximo 8 ocorrências
...OU...
router-quagga(config)#ip as-path access-list PATH-AS-20 permit ^20(_20)*$
!--- Essa expressão não limita a quantidade de prepends
router-quagga(config)#route-map ANUNCIAR-AS-XXX permit 10

router-quagga(config-route-map)#match ip address prefix-list BLOCOS-AS-20
router-quagga(config-route-map)#match as-path PATH-AS-20
622
 Com apenas 2 comandos oS AS's 611XX e 6110Z estão

liberados nos filtros de saída:
AS-X-R1(config)#ip as-path access-list 30 permit ^(40X ?)+( 6110X ?)+$
Já
AS-X-R1(config)#ip as-path access-list 30 permit ^(40X ?)+$
ex
iste
AS-X-R1(config)#ip as-path access-list 40 permit ^(50X ?)+( 6110Z ?)+$
Já
ex
is
AS-X-R1(config-route-map)# match as-path 30
te
623


AS-X-R1#show running-config | begin BLOCOS-AS-40X

ip prefix-list BLOCOS-AS-40X seq 5 permit 154.X.0.0.0/16 le 24
ip prefix-list BLOCOS-AS-40X seq 10 permit 161.X.0.0/22 le 24
!
ip prefix-list BLOCOS-AS-50X seq 10 permit 161.Z.0.0/22 le 24
!
624
 Com apenas 2 comandos em cada ACL os AS's 611XX e

6110Z estão liberados nos filtros de saída:
AS-X-R2(config)#ip as-path access-list 30 permit ^(40X ?)+( 611XX ?)+$
Já
ex
iste
Já
ex
is
te
625



ip prefix-list BLOCOS-AS-40X seq 10 permit 161.X.0.0/22 le 24
!
ip prefix-list BLOCOS-AS-50X seq 10 permit 161.Z.0.0/22 le 24
!
626
7.3
AS de Trânsito no PTT
parte I
627
7.3 - AS de Trânsito no PTT – parte I
 Configurando as políticas de route-map
 AS-X-R1
!--- ATENÇÃO TODAS AS PREFIX-LIST ABAIXO JÁ FORAM CRIADAS NOS LABS ANTERIORES
!--- ESTÃO AQUI APENAS PARA LEMBRAR O SEU CONTEÚDO
!--- CASO ESTAS NÃO ESTEJAM PRESENTES CONFIGUREM NOVAMENTE
!--- AS-X-R1(config)#ip prefix-list MEUS-BLOCOS permit X.0.0.0/8
!--- AS-X-R1(config)#ip prefix-list BLOCOS-AS-10X permit 187.X.0.0.0/22 le 24
!--- AS-X-R1(config)#ip prefix-list BLOCOS-AS-40X permit 154.X.0.0/16 le 24
!--- apenas 2 dos filtros baseados em ASPATH ainda não foram criados
AS-X-R1(config)#ip as-path access-list 30 permit ^(40X ?)+( 6110X ?)+$
!--- em seguida o primeiro o route-map que trata os filtros de input para redes recebidas do PTT
AS-X-R1(config)#route-map CLIENTE-AS-10X-IN permit 10
(continua...)
LAB 2-3-1 628

 Configurando as políticas de route-map para o PTT
 AS-X-R1
(...continuação)
!--- libera os blocos do AS local X
!--- libera os blocos do DOWNSTREAM 1
(continua...)
LAB 2-3-1 629

 Configurando as políticas de route-map para o AS 100
 AS-X-R1
(...continuação)
AS-X-R1#clear ip bgp * soft
LAB 2-3-1 630

 AS-X-R1
(...continuação)
LAB 2-3-1 631

 Configurando as políticas de route-map
 AS-X-R2
!--- ATENÇÃO TODAS AS PREFIX-LIST ABAIXO JÁ FORAM CRIADAS NOS LABS ANTERIORES
!--- ESTÃO AQUI APENAS PARA LEMBRAR O SEU CONTEÚDO
!--- AS-X-R2(config)#ip prefix-list MEUS-BLOCOS permit X.0.0.0/8
!--- AS-X-R2(config)#ip prefix-list BLOCOS-AS-10X permit 187.X.0.0.0/22 le 24
!--- CASO ESTAS NÃO ESTEJAM PRESENTES CONFIGUREM NOVAMENTE
!--- apenas os filtros baseados em ASPATH ainda não foram criados
AS-X-R2(config)#ip as-path access-list 30 permit ^(40X ?)+( 6110X ?) +$
!--- em seguida o primeiro o route-map que trata os filtros de input para redes recebidas do PTT
AS-X-R2(config)#route-map CLIENTE-AS-10X-IN permit 10
(continua...)
LAB 2-3-1 632

 Configurando as políticas de route-map para o PTT
 AS-X-R2
(...continuação)
(continua...)
LAB 2-3-1 633

 AS-X-R2
(...continuação)
LAB 2-3-1 634

 AS-X-R2
(...continuação)
LAB 2-3-1 635

 PS: nos LABs anteriores já configuramos as mesmas

políticas para o output do AS 100, vamos apenas conferir:
AS-X-R1#show running-config | begin ANUNCIAR-AS-100
route-map ANUNCIAR-AS-100 permit 10
match ip address prefix-list MEUS-BLOCOS
match as-path 10
!
match as-path 20
!
match as-path 30
!
 Como podemos ver na saida do comando, as políticas de
output com o AS 100 já estão configuradas.
 O mesmo resultado deve aparecer em R2
LAB 2-3-1 636

 A configuração nos DOWNSTREAMS é muito mais simples:

 AS-40X-R1
set protocols bgp group eBGP-PTT export PTT-SP-OUT
set protocols bgp group eBGP-PTT peer-as 555
set protocols bgp group eBGP-PTT neighbor 187.16.216.254
set protocols bgp group eBGP-PTT neighbor 187.16.216.253
set policy-options policy-statement PTT-SP-OUT term 1 from route-filter 154.X.0.0/17 exact
set policy-options policy-statement PTT-SP-OUT term 1 from route-filter 154.X.128.0/17 exact
set policy-options policy-statement PTT-SP-OUT term 1 then accept
set policy-options policy-statement PTT-SP-OUT term 2 from route-filter 161.X.0.0/22 upto /24
set policy-options policy-statement PTT-SP-OUT term 2 then accept
set policy-options policy-statement PTT-SP-OUT then reject

LAB 2-3-1 637

 Seguimos a mesma lógica para o segundo DOWNSTREAM

 AS-50X-R1
AS-50X-R1#conf t
AS-50X-R1(config)#ip prefix-list MEUS-BLOCOS permit 155.X.0.0/17
AS-50X-R1(config)#ip prefix-list MEUS-BLOCOS permit 155.X.128.0/17
AS-50X-R1(config)#ip route 155.X.0.0 255.255.128.0 null 0
AS-50X-R1(config)#ip route 155.X.128.0 255.255.128.0 null 0
AS-50X-R1(config)#router bgp 50X
AS-50X-R1(config-router)#no bgp enforce-first-as
AS-50X-R1(config-router)#network 155.X.0.0 mask 255.255.128.0
AS-50X-R1(config-router)#network 155.X.128.0 mask 255.255.128.0
AS-50X-R1(config-router)#neighbor PTT peer-group
AS-50X-R1(config-router)#neighbor PTT remote-as 555
AS-50X-R1(config-router)#neighbor PTT soft-reconfiguration inbound
AS-50X-R1(config-router)#neighbor PTT prefix-list MEUS-BLOCOS out
AS-50X-R1(config-router)#neighbor PTT weight 50
AS-50X-R1(config-router)#neighbor PTT send-community both
AS-50X-R1(config-router)#neighbor 187.16.216.253 peer-group PTT
AS-50X-R1(config-router)#neighbor 187.16.216.253 description PTT RS 1
AS-50X-R1(config-router)#neighbor 187.16.216.254 peer-group PTT
AS-50X-R1(config-router)#neighbor 187.16.216.254 description PTT RS 2
AS-50X-R1(config-router)#neighbor 187.16.216.252 remote-as 555
AS-50X-R1(config-router)#neighbor 187.16.216.252 description LG do PTT
AS-50X-R1(config-router)#end
LAB 2-3-1 638
 As sessões BGP do DOWNSTREMS 14X com o PTT não

estabeleceu!
 O que faltou?
 Os testes de ping com o Route-Server tem resposta?
639
7.4
Configurando um Transporte
Lan2Lan com xconnect/L2TP
640
7.4 – Configurando um Transporte
AS-X-R4(config)#l2tp-class transporte-l2
AS-X-R4(config-l2tp-class)#cookie size 4
AS-X-R4(config-l2tp-class)#exit
!--- Declaramos uma class e demos o nome de “transporte-l2”
AS-X-R4(config)#pseudowire-class transporte-l2
AS-X-R4(config-pw-class)#encapsulation l2tpv3
AS-X-R4 (config-pw-class)#protocol none
AS-X-R4 (config-pw-class)#ip local interface Loopback0
!--- Na configuração da class escolhemos o tipo de tunelamento que em nosso caso será l2tp versão 3.
AS-X-R4 (config-pw-class)#exit
AS-X-R4(config)#interface f0/1
AS-X-R4(config)#no shut
AS-X-R4(config-if)#xconnect X.0.0.1 40X encapsulation l2tpv3 manual pw-class transporte-l2
AS-X-R4(config-if-xconn)#l2tp id 1 1
AS-X-R4(config-if-xconn)#l2tp cookie local 4 1
AS-X-R4(config-if-xconn)# l2tp cookie remote 4 1
LAB 2-4-1 641

AS-X-R1(config)#l2tp-class transporte-l2
AS-X-R1(config-l2tp-class)#cookie size 4
AS-X-R1(config-l2tp-class)#exit
!--- Declaramos uma class e demos o nome de “transporte-l2”
AS-X-R1(config)#pseudowire-class transporte-l2
AS-X-R1(config-pw-class)#encapsulation l2tpv3
AS-X-R1 (config-pw-class)#protocol none
AS-X-R1 (config-pw-class)#ip local interface Loopback0
!--- Na configuração da class escolhemos o tipo de tunelamento que em nosso caso será l2tp versão 3.
AS-X-R1 (config-pw-class)#exit
AS-X-R1(config)#no shut
AS-X-R1(config-if)#xconnect X.0.0.4 40X encapsulation l2tpv3 manual pw-class transporte-l2
AS-X-R1(config-if-xconn)#l2tp id 1 1
AS-X-R1(config-if-xconn)#l2tp cookie local 4 1
AS-X-R1(config-if-xconn)# l2tp cookie remote 4 1
LAB 2-4-1 642

AS-X-R1#sh l2tun
%No active L2F tunnels
L2TP Tunnel and Session Information Total tunnels 0 sessions 1
LocID RemID TunID Username, Intf/ State Last Chg Uniq ID
Vcid, Circuit
1 1 0 14X, Fa2/0 est 00:00:24 1
AS-X-R4#sh l2tun
%No active L2F tunnels
L2TP Tunnel and Session Information Total tunnels 0 sessions 1
LocID RemID TunID Username, Intf/ State Last Chg Uniq ID
Vcid, Circuit
1 1 0 14X, Fa0/0 est 00:00:43 1
LAB 2-4-1 643

7.5 - AS de Trânsito no PTT – parte II
 Vamos entrar no AS-100-R1 (100.100.100.1) e fazer um

traceroute para os DOWNSTREAMS do grupo.
 Notem que ao entrar no AS do GRUPO, os pacotes são

encaminhados para o PTT, e não chegam ao
DOWNSTREAM pelo link de trânsito.
 Mesmo com um local preference maior, os prefixos que os

AS's 40X e AS 50X anunciam para PTT são mais
específicos do que os que anunciam para o trânsito, isso
obriga o router R1 a mandar os pacotes pelo PTT
(download dos DOWNSTREAMS).
644
 Isso é um problema sério!
 O cliente pode tirar proveito disso e causar prejuízos

”desviando” trânsito IP, obrigando AS local a ”trocar” o
trânsito IP por ”nada”.
 Uma troca de tráfego onde apenas um tem vantagem...
645
 Para resolver isso, precisamos utilizar uma expressão

regular proibindo R1 de receber qualquer anúncio de
participantes que também sejam clientes de trânsito do
AS:
AS-X-R1#conf t
AS-X-R1(config)#ip as-path access-list 55 permit _40X_
AS-X-R1(config)#ip as-path access-list 55 permit _50X_
AS-X-R1(config)#route-map PTT-IN deny 5
 Inserimos o AS de cada cliente de trânsito nessa lista.

 Vale lembrar que em certos casos, os filtros precisariam ser
mais específicos, fazendo um route-map de deny para
cada cliente, combinando uma prefix-list + as-path
access-list
LAB 2-4-1 646
 Vamos efetuar novamente o traceroute partindo de AS-110-

R1...
647
7.5
PERGUNTAS?
648
8.0
Multiprotocol Label Switching

(MPLS)
649
8.0
Multiprotocol Label
Switching (MPLS)
8. Multiprotocol Label Switching
• 8.1 BGP através da nuvem MPLS

• 8.2 AtoM - Any Transport Over MPLS
• 8.3 Implementando serviço VPN-L3 (VPN-Multiponto)
650
8.1
BGP Através da Nuvem MPLS
(BGP Multiprotocol)
651
8.1 – BGP através da nuvem MPLS
 Entendendo os campos do quadro ethernet
LAB 2-5-1 652

LAB 2-5-1 653

LAB 2-5-1 654

AS-X-R3(config-if)#mpls label protocol both
AS-X-R3(config-if)#mtu 1600
AS-X-R3(config-if)#mpls ip
AS-X-R3(config-if)#mpls mtu 1508
AS-X-R3(config-if)#
*Mar 1 00:13:29.699: %TFIB-3-MPLS_MTU_SET: Setting mpls mtu to 1508 on Serial1/0
which is higher than the interface mtu 1500 . This could lead to packet forwarding problems
including packet drops.exit
AS-X-R3(config-if)#exit
!--- Configurando LDP com R1
AS-X-R3(config-if)#
including packet drops.
(...)
LAB 2-5-1 655
(...)
AS-X-R3(config-if)#
AS-X-R3(config-if)#
LAB 2-5-1 656
*Mar 1 00:18:23.703: %LDP-5-NBRCHG: LDP Neighbor X.0.0.3:0 (1) is UP
AS-X-R1(config-if)#
LAB 2-5-1 657

AS-X-R2(config-if)#
AS-X-R2(config-if)#
LAB 2-5-1 658

AS-X-R4(config)#interface G3/0
AS-X-R4(config-if)#
AS-X-R4(config-if)#
LAB 2-5-1 659

AS-X-R5(config-if)#
LAB 2-5-1 660

 Configurando iBGP entre R1-R2, R1-R4 e R1-R5:
AS-X-R1#conf t
AS-X-R1(config)#bgp cluster-id 0.0.0.1
!--- Configurando iBGP padrão com R2
(...)
LAB 2-5-1 661

 Configurando Multiprotocol BGP entre R1-R2, R1-R4 e R1-R5:
(...)
AS-X-R1(config-router)#address-family vpnv4
!--- Entra no address family VPNv4
AS-X-R1(config-router-af)#neighbor X.0.0.2 activate
!--- Adiciona esse neighbor ao modo VPNv4
AS-X-R1(config-router-af)#neighbor X.0.0.2 route-reflector-client
AS-X-R1(config-router-af)#neighbor X.0.0.2 send-community both
!--- Habilida o envio de communities padrão e também do tipo estendida
LAB 2-5-1 662

 Configurando iBGP entre R2-R1, R2-R4 e R2-R5:
AS-X-R2#conf t
AS-X-R2(config)#bgp cluster-id 0.0.0.2
(...)
LAB 2-5-1 663

 Configurando Multiprotocol BGP entre R2-R1, R2-R4 e R2-R5:
(...)
LAB 2-5-1 664

 Configurando iBGP entre R4-R1 e R4-R2
AS-X-R4#conf t
(...)
LAB 2-5-1 665

 Configurando Multiprotocol BGP entre R4-R1 R4-R2:
(...)
LAB 2-5-1 666

 Configurando iBGP entre R5-R1 e R5-R2
AS-X-R5#conf t
(...)
LAB 2-5-1 667

 Configurando Multiprotocol BGP entre R5-R1 R5-R2:
(...)
LAB 2-5-1 668

 Testando...
juniper@AS-40X-R1> traceroute 123.123.123.1

1 X.104.1.1 (3.104.1.1) 2.985 ms 3.940 ms 5.234 ms
2 ***
3 ***
LAB 2-5-1 669

 Testando...
juniper@AS-40X-R1> traceroute 123.123.123.1 source 154.X.0.1

traceroute to 123.123.123.1 (123.123.123.1) from 154.2.0.1, 30 hops max, 40 byte
packets
1 2.104.1.1 (2.104.1.1) 4.375 ms 9.072 ms 10.182 ms
2 2.2.4.1 (2.2.4.1) 50.816 ms 49.888 ms 52.100 ms AS-X-R3#sh ip bgp
MPLS Label=16 CoS=0 TTL=1 S=1 % BGP not active
3 2.2.1.1 (2.2.1.1) 50.056 ms 49.944 ms 50.768 ms
4 200.2.1.1 (200.2.1.1) 71.068 ms 69.803 ms 71.942 ms
5 200.200.2.1 (200.200.2.1) 92.618 ms 80.272 ms 81.409 ms
6 222.200.1.1 (222.200.1.1) 101.927 ms 102.034 ms 101.199 ms
7 222.222.1.1 (222.222.1.1) 121.501 ms 119.899 ms 121.889 ms
8 123.222.1.1 (123.222.1.1) 141.717 ms * 133.866 ms
LAB 2-5-1 670

 Corrigindo...
AS-X-R1(config-router)#network 100.X.1.0 0.0.0.3 area 0
AS-X-R1(config-router)#passive-interfa gigabitEthernet 1/0
AS-X-R1(config-router)#passive-interface gigabitEthernet 2/0
AS-X-R1(config-router)#network 187.16.216.0 0.0.3.255 area 0
AS-X-R1(config-router)#passive-interface fastEthernet 0/1
AS-X-R2(config-router)#network 200.219.138.0 0.0.0.255 area 0
LAB 2-5-1 671

 Corrigindo...
AS-X-R4(config-router)#network X.104.1.0 0.0.0.3 area 0
AS-X-R4(config-router)#passive-interface GigabitEthernet 4/0
AS-X-R5(config-router)#passive-interface GigabitEthernet 4/0
LAB 2-5-1 672

 Testando...
juniper@AS-40X-R1> traceroute 123.123.123.1

1 3.104.1.1 (3.104.1.1) 2.790 ms 4.560 ms 5.020 ms
2 3.3.4.1 (3.3.4.1) 25.454 ms 24.729 ms 25.484 ms
MPLS Label=16 CoS=0 TTL=1 S=1
3 3.3.1.1 (3.3.1.1) 25.476 ms 24.991 ms 25.174 ms
4 200.3.1.1 (200.3.1.1) 30.598 ms 30.066 ms 30.791 ms
5 222.200.1.1 (222.200.1.1) 35.367 ms 35.104 ms 35.760 ms
6 222.222.1.1 (222.222.1.1) 45.690 ms 50.559 ms 45.268 ms
7 123.222.1.1 (123.222.1.1) 60.768 ms * 51.998 ms
LAB 2-5-1 673

8.1
PERGUNTAS?
674
8.2
AToM
Any Trasnport Over MPLS
675
8.2 AtoM - Any Transport Over MPLS
Cenário:
40X
50X
R2 R5 50X
F0/1
AS-X
R3
F0/0
R1 R4 40X
G6/0
PTT-SP
goo.gl/kIcIbX
676
AS-X-R1(config)#pseudowire-class VPN-MPLS-PTT-SP
AS-X-R1(config-pw-class)#encapsulation mpls
AS-X-R1(config-pw-class)#exit
AS-X-R1(config-if)#no ip address
AS-X-R1(config-if)#no xconnect
AS-X-R1(config-if)#xconnect X.0.0.4 40X pw-class VPN-MPLS-PTT-SP
AS-X-R1(config-if-xconn)#end
LAB 2-6-1 677

AS-X-R4(config)#pseudowire-class VPN-MPLS-PTT-SP
AS-X-R4(config-pw-class)#encapsulation mpls
AS-X-R4(config-pw-class)#exit
AS-X-R4(config)#interface fastEthernet 0/1
AS-X-R4(config-if)#no ip address
AS-X-R4(config-if)#no xconnect
AS-X-R4(config-if)#xconnect X.0.0.1 40X pw-class VPN-MPLS-PTT-SP
AS-X-R4(config-if-xconn)#end
AS-X-R4#show xconnect all

Legend: XC ST=Xconnect State, S1=Segment1 State, S2=Segment2 State
UP=Up, DN=Down, AD=Admin Down, IA=Inactive, NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP ac Fa0/1(Ethernet) UP mpls X.0.0.1:40X UP
AS-X-R4#
LAB 2-6-1 678

8.2
PERGUNTAS?
679
8.3
Implementando serviço
VPN-Layer 3
(MPLS-VPN)
680
8.3 Implementando serviço VPN-L3
Cenário:
40X
50X
R2 R5 50X
F0/1
AS-X
R3
F0/0
R1 R4 40X
G6/0
PTT-SP
goo.gl/kIcIbX
681
Configurando VRF do AS-40X-R2

AS-X-R2#conf t
AS-X-R2(config)#ip vrf VPN-AS-40X
AS-X-R2(config-vrf)#rd X:40X
AS-X-R2(config-vrf)#route-target export X:40X
AS-X-R2(config-vrf)#route-target import X:40X
AS-X-R2(config-vrf)#exit
AS-X-R2(config-if)#ip vrf forwarding VPN-AS-40X
% Interface GigabitEthernet4/0 IP address X.104.2.1 removed due to enabling VRF VPN-AS-40X
AS-X-R2(config-if)#ip address X.104.2.1 255.255.255.252
AS-X-R2#ping vrf VPN-AS-40X X.104.2.2

!!!!!
AS-X-R1#
LAB 2-7-1 682
Configurando BGP com AS-40X-R2

AS-X-R2#conf t
AS-X-R2(config-router)#address-family ipv4 vrf VPN-AS-40X
AS-X-R2(config-router-af)#redistribute connected
AS-X-R2(config-router-af)#neighbor X.104.2.2 remote-as 6410X
AS-X-R2(config-router-af)#no synchronization
AS-X-R2(config-router-af)#end
LAB 2-7-1 683

Acessando AS-40X-R2
AS-X-R2#telnet X.104.2.2 /vrf VPN-AS-40X
MikroTik v5.26
Login: admin
Password:
[admin@MikroTik] > /system identity set name=AS-40X-R2

[admin@AS-40X-R2] > /routing bgp instance set 0 as=6410X
[admin@AS-40X-R2] > /routing bgp network add network=192.168.0.0/24 synchronize=no
[admin@AS-40X-R2] > /routing bgp peer add remote-address=X.104.2.1 remote-as=X
[admin@AS-40X-R2] > /interface bridge add name=loopback
[admin@AS-40X-R2] > /ip address add address=192.168.0.1/32 interface=loopback
[admin@AS-40X-R2] > /quit
interrupted

AS-X-R2#
LAB 2-7-1 684

AS-X-R2#conf t
AS-X-R2(config-if)#no shut

!!!!!
AS-X-R2#
LAB 2-7-1 685

AS-X-R2#conf t
LAB 2-7-1 686

Acessando AS-50X-R2
MikroTik v5.26
Login: admin
Password:

[admin@AS-50X-R2] > /routing bgp networkadd network=192.168.0.0/24 synchronize=no
interrupted

AS-X-R2#
LAB 2-7-1 687

AS-X-R4#conf t
AS-X-R4(config)#interface gigabitethernet 4/0

!!!!!
LAB 2-7-1 688

AS-X-R4#conf t
AS-X-R4#
LAB 2-7-1 689

Acessando AS-40X-R3
MikroTik v5.26
Login: admin
Password:

LAB 2-7-1 690

Testando conectivivade com o outro lado da VPN

[admin@AS-40X-R3] > /ip route print
1 ADb X.104.2.0/30 X.104.3.1 20
2 ADC X.104.3.0/30 X.104.3.2 ether1 0
3 Db X.104.3.0/30 X.104.3.1 20
4 ADC 172.16.0.1/32 172.16.0.1 loopback 0
5 ADb 192.168.0.0/24 X.104.3.1 20
[admin@AS-40X-R3] >
LAB 2-7-1 691

[admin@AS-416-R3] > tool traceroute 192.168.0.1

# ADDRESS RT1 RT2 RT3 STATUS
1 X.104.3.1 8ms 4ms 8ms
2 X.X.4.1 55ms 70ms 58ms <MPLS:L=17,E=0 ...
3 X.104.2.1 45ms 45ms 46ms <MPLS:L=29,E=0>
4 192.168.0.1 54ms 56ms 58ms
[admin@AS-40X-R3] >
LAB 2-7-1 692


AS-X-R5#conf t
AS-X-R5(config)#interface gigabitethernet 4/0

!!!!!
LAB 2-7-1 693


AS-X-R5#conf t
LAB 2-7-1 694

Acessando AS-50X-R3
MikroTik v5.26
Login: admin
Password:

interrupted
LAB 2-7-1 695


[admin@AS-50X-R3] > /ip route print
1 ADb X.104.2.0/30 X.104.3.1 20
2 ADC X.104.3.0/30 X.105.3.2 ether1 0
3 Db X.104.3.0/30 X.104.3.1 20
4 ADC 172.16.0.1/32 172.16.0.1 loopback 0
5 ADC 172.20.199.0/24 172.20.199.3 ether1 0
6 ADb 192.168.0.0/24 X.104.3.1 20
[admin@AS-50X-R3] >
LAB 2-7-1 696

[admin@AS-50X-R3] > tool traceroute 192.168.0.1

# ADDRESS RT1 RT2 RT3 STATUS
1 X.105.3.1 8ms 4ms 8ms
2 X.X.5.1 55ms 70ms 58ms <MPLS:L=17,E=0 ...
3 X.105.2.1 45ms 45ms 46ms <MPLS:L=29,E=0>
4 192.168.0.1 54ms 56ms 58ms
[admin@AS-50X-R3] >
LAB 2-7-1 697

AS-X-R2#sh ip bgp vpnv4 vrf VPN-AS-40X


Route Distinguisher: 1:141 (default for vrf vpn-as141)
*> X.104.2.0/30 0.0.0.0 0 32768 ?
*>iX.104.1.0/30 X.0.0.4 0 100 0?
*>i X.0.0.4 0 100 0?
* i 172.16.0.0/24 X.0.0.4 0 100 0 6410X i
*>i X.0.0.4 0 100 0 6420X i
*> 192.168.0.0 X.104.2.2 0 0 6420X i
LAB 2-7-1 698

AS-X-R2#sh ip bgp vpnv4 vrf VPN-AS-40X 172.16.0.0

BGP routing table entry for X:0X:172.16.0.0/24, version 11
Paths: (2 available, best #2, table VPN-AS-40X)
1 2
6420X, (Received from a RR-client)
X.0.0.4 (metric 3) from X.0.0.1 (X.0.0.1)
Origin IGP, metric 0, localpref 100, valid, internal
Extended Community: RT:16:416
Originator: 16.0.0.4, Cluster list: 0.0.0.1
mpls labels in/out nolabel/33
X.0.0.4 (metric 3) from X.0.0.4 (X.0.0.4)
Extended Community: RT:X:40X
LAB 2-7-1 699

AS-X-R2#show mpls forwarding-table

Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag X.X.2.0/30 0 Se1/1 point2point
17 Pop tag X.0.0.3/32 0 Se1/1 point2point
18 17 X.0.0.2/32 0 Se1/1 point2point
20 18 X.0.0.5/32 0 Se1/1 point2point
22 19 X.0.0.4/32 0 Se1/1 point2point
23 20 X.X.100.0/30 0 Se1/1 point2point
25 l2ckt(999) 104473 none point2point
26 Aggregate X.104.2.0/30[V] 520
28 Untagged 192.168.0.0/24[V] 1768 Se1/2 point2point
AS-X-R1#
LAB 2-7-1 700

AS-X-R2#sh ip bgp vpnv4 vrf VPN-AS-50X


Route Distinguisher: X:15X (default for vrf vpn-as151)
*> X.104.2.0/30 0.0.0.0 0 32768 ?
*>iX.104.1.0/30 X.0.0.5 0 100 0?
*>i X.0.0.5 0 100 0?
* i 172.16.0.0/24 X.0.0.5 0 100 0 6510X i
*>i X.0.0.5 0 100 0 6520X i
*> 192.168.0.0 X.105.2.2 0 0 6520X i
LAB 2-7-1 701

AS-X-R2#sh ip bgp vpnv4 vrf VPN-AS-50X 172.16.0.0

BGP routing table entry for X:50X:172.16.0.0/24, version 9
Paths: (1 available, best #1, table VPN-AS-50X)
1
6520X
X.0.0.5 (metric 3) from X.0.0.5 (X.0.0.5)
X.0.0.5 (metric 3) from X.0.0.5 (X.0.0.5)
AS-X-R2#
LAB 2-7-1 702

AS-X-R2#show mpls forwarding-table

Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 16 X.0.0.1/32 0 Se1/1 point2point
18 Pop tag X.0.0.3/32 0 Se1/1 point2point
20 18 X.0.0.5/32 0 Se1/1 point2point
22 19 X.0.0.4/32 0 Se1/1 point2point
23 20 X.X.100.0/30 0 Se1/1 point2point
25 l2ckt(999) 107714 none point2point
26 Aggregate X.15X.2.0/30[V] 0
28 Untagged 192.168.0.0/24[V] 0 Se1/2 point2point
AS-X-R2#
LAB 2-7-1 703

8.3
PERGUNTAS?
704
9.1
Hardware
sobressalente
com VRRP
705
9.1-Hardware sobressalente com VRRP
 O cenário permanece o mesmo, porém com um router
“identico” como backup.
 A ideia é que todos os dois links continuem 100%
operacional mesmo que o router principal fique
totalmente fora.
LAB 1-5-1 706

 Antes de configurar o router BACKUP, vamos NOVAMENTE

anunciar apenas um bloco /8 para cada operadora:
 Criando as prefix-lists:
GX-R1(config-router)#neighbor 200.X.1.1 prefix-list MEUS-BLOCOS out
!---mudar o filtro na saída do AS 200

!--- mudar o filtro na saída do AS 100
GX-R1#clear ip bgp *
LAB 1-5-1 707

 O segundo router responde pelo IP X.128.0.253

uma sessão telnet da mesma forma que fizemos com GX-
R1:
Trying X.128.0.253...
Connected to X.128.0.253.
Password: A senha de acesso também é 123
LAB 1-5-1 708

 Estamos agora no modo ”usuário”:

GX-R2>
 A senha de enable mudou:

G1-R2>enable
Password: gXr2
GX-R2#
 Todos os outros passos são semelhantes...

GX-R2#terminal monitor
GX-R2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
GX-R2(config)#
LAB 1-5-1 709

 Precisamos aplicar as MESMAS configurações, com exceção

dos endereços de neighbor:
!-- ATENÇÂO as configurações são em Gx-R2
!-- observem a mudança no IP de neighbor
GX-R2(config)# router bgp X

GX-R2(config-router)#
network x.0.0.0 mask 255.0.0.0
no auto-summary
neighbor 100.X.2.1 remote-as 100
neighbor 100.X.2.1 description eBGP com as 100
neighbor 200.X.2.1 remote-as 200
neighbor 200.X.2.1 description eBGP com as 200
LAB 1-5-1 710
 Criando as prefix-lists:
GX-R2(config)#ip prefix-list MEUS-BLOCOS permit X.0.0.0/8
!--- adiciona o bloco do AS do grupo na lista ”MEUS-BLOCOS”
GX-R2(config)#ip route X.0.0.0 255.0.0.0 null 0
!---aplicar o mesmo filtro na saída do AS 200

!--- aplicar o mesmo filtro na saída do AS 100
LAB 1-5-1 711

 Verificando o status das sessões BGP recém-criadas:

GX-R2#sh ip bgp summary
100.X.2.1 4 100 192 170 9 0 0 00:00:48 7
200.X.2.1 4 200 191 181 9 0 0 00:00:51 7
 O número de PfxRcd vai ser maior a medida que os alunos estabeleceram

suas conexões.
LAB 1-5-1 712

 Verificando as rotas recebidas após o filtro de

saída:
GX-R2>sh ip bgp neighbors 100.X.2.1 advertised-route
BGP table version is 24, local router ID is X.X.X.X

*> X.0.0.0 0.0.0.0 0 32768 i
GX-R2>sh ip bgp neighbors 200.X.2.1 advertised-routes

BGP table version is 24, local router ID is X.X.X.X

*> X.0.0.0 0.0.0.0 0 32768 i
LAB 1-5-1 713

 O próximo passo é a criação da interface virtual, mas o que

é VRRP afinal?
 Virtual Router Redundancy Protocol
cria uma interface, um MAC e um
ip virtual, e todos os routers do
grupo VRRP conhecem essas
informaçes. No momento em que
o router “master” fica fora, o
primeiro candidato levanta
imediatamente o IP virtual, de
maneira que os hosts da rede não
percebem essa comutação, e ao
mesmo tempo não tem problemas
com ARP, já que o MAC não muda.
LAB 1-5-1 714

 O próximo passo é a criação da interface virtual, mas o que

é VRRP afinal?
 Vários roteadores podem fazer parte
de uma mesma VRRP. Para definir
quem é o router master e quem
assume nas situações de falha,
alteramos o valor de priority na
configuração do grupo VRRP.
 Vamos à segunda parte do LAB...
LAB 1-5-2 715

 Vamos configurar uma VRRP na interface lan e garantir que

GX-R1 seja o router master: GX-R1#conf t
GX-R1(config)#interface fastEthernet 0/0
GX-R1(config-if)#vrrp X ip X.128.0.252
GX-R1(config-if)#vrrp X priority 2
GX-R1(config-if)#vrrp X timers advertise 1
GX-R1(config-if)#vrrp X preempt delay minimum 160
GX-R1(config-if)#end
GX-R1#debug vrrp state
VRRP State debugging is on
GX-R1#wr
GX-R2#conf t
GX-R2(config)#interface fastEthernet 0/0
GX-R2(config-if)#vrrp X ip X.128.0.252
GX-R2(config-if)#vrrp X priority 1
GX-R2(config-if)#vrrp X timers learn
GX-R2(config-if)#vrrp X preempt delay minimum 160
GX-R2(config-if)#end
GX-R2#debug vrrp state
VRRP State debugging is on
GX-R2#wr
LAB 1-5-2 716

 Vamos verificar o
status...
GX-R1#sh vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Fa0/0 X 2 3992 Y Master X.128.0.254 X.128.0.252
GX-R1#
GX-R2#sh vrrp brief

Interface Grp Pri Time Own Pre State Master addr Group addr
Fa0/0 X 1 3992 Y Backup X.128.0.254 X.128.0.252
GX-R2#
LAB 1-5-2 717

 Agora simularemos uma falha em GX-R1
 Notem que há um tempo médio de 4 minutos até que a comutação

aconteça para o router backup
 Por que todo esse tempo?
LAB 1-5-2 718

9.3-BGP Timers, reduzindo o tempo de
convergência de links
 Quando o router R1 fica fora, os CPE's das

operadoras passam algum tempo “pensando”
que ele ainda está UP Cada router envia uma mensagem “keep alive” a cada 60 segundos

(por padrão)
 Quando um “keep alive” atrasa, o CPE da operadora ativa uma

contagem chamada “hold time” (padrão 180 segundos)
X 

Se até o final do “hold time” não chegar um “keep alive” o CPE da
operadora finaliza a sessão BGP com R1.
Imediatamente o CPE percebe que há uma outra opção disponível

para a rede X.0.0.0/8 e instala em sua FIB
 Vamos alterar os valores de “keep alive” e “hold time” para 5 e 15

segundos respectivamente...
LAB 1-5-2 719

 Vamos alterar os timers padrão para diminuir o

downtime
GX-R1(config-router)#neighbor 100.X.1.1 timers 5 15
!--- muda o tempo de keep alive para 5 segundos
!--- e o hold time para 15 segundos
!--- muda o tempo de keep alive para 5 segundos
!--- e o hold time para 15 segundos
LAB 1-5-2 720
 Vamos testar novamente...
 O tempo paralização diminuiu de cerca de 3 minutos para 15

segundos
É importante lembrar que nesse lab utilizamos interfaces seriais, e o
X

“bgp fast-external-fallover” vem habilitado por padrão e faz o BGP

automaticamente finalizar a sessão quando detecta uma interface em
estado “down”.
 Esse recurso foi desabilitado no intuito de simular situações reais já

qua a maioria dos links atuais são “metroethernet”
LAB 1-5-2 721

9.3
PERGUNTAS?
722
MATERIAL
EXTRA
O trabalho Curso de BGP Design com Roteadores Cisco de Rinaldo Vaz foi licenciado com
uma Licença Creative Commons - Atribuição 3.0 Não Adaptada.
Podem estar disponíveis autorizações adicionais ao âmbito desta licença em
rinaldopvaz@gmail.com.
723
10.0
Mecanismos de Path Control
724
9.0
Mecanismos de Path
Control
8. Mecanismos de Path Control
• 8.1 PBR – Policy Based Routing

• 8.2 IP SLA Tool
 Agradecimentos especiais para Roberto Mendonça, autor dos

dois próximos sub-capítulos
725
9.1 PBR – Policy Based Routing
 Mecanismos de Path Control

 Path Control são mecanismos que mudam o
encaminhamento
padrão de um pacote através de uma rede.
 Não se trata de QoS ou Engenharia de Tráfego.
 Trata-se de uma coleção de ferramentas ou conjunto de
comandos que são ativados para manipular a tabela de
encaminhamento de um protocolo de roteamento ou
bypass o
encaminhamento padrão de um pacote.
 Esta manipulação de informações de roteamento pode ser
requerida para obter melhor desempenho.
726
 Alguns Tópicos para Implementar Path Control
– PBR – Policy-Based Routing;
– IP SLA Tool (Service Level Agreements)
727
 Para entender PBR, primeiro precisamos

revisitar o conceito de roteamento padrão:
✔ 1.Quando um pacote chega à uma interface de um router,
este examina o endereço de destino do pacote contra a
sua tabela de roteamento.
✔ 2. Se a rede destino for conhecida pelo router (ou seja,
constar na tabela), o pacote é encaminhado para a
interface de saída indicada.
✔ 3. Se a rede destino não for conhecida e existir uma rota
default, o pacote é encaminhado para a interface de saída
apontada por ela.
✔ 4. Se nenhum dos dois casos acima ocorrer, o router
descarta o pacote.
728
 Policy-based routing quebra o processo default de

roteamento, permitindo que pacotes sejam roteados
baseados em políticas pré-definidas e não apenas no
endereço de destino.
 Para isso, ROUTE-MAPs são usados, especificando condições

que devem ser examinadas e para onde os pacotes
devem ser encaminhados caso estas condições sejam
verificadas.
729
 Um exemplo genérico de aplicação de PBRs pode ser visto

na figura abaixo:
730
 Para implementar o cenário ilustrado anteriormente, apenas

três passos são necessários:
 1. Defina um route-map e a política que identificará o

pacote (MATCH);
 2. Defina para onde o pacote deve ir, caso um MATCH ocorra

(SET);
 3. Aplique o route-map na interface para análise dos

pacotes à medida que entram (IN).
731
 Ao criar um route-map para ser usado com PBR, existem

algumas opções de MATCH à escolher, por exemplo:
– Match ip address (utiliza listas de acesso para

checagem)
– Match lenght (utiliza um intervalo mínimo e máximo do

tamanho do pacote, em bytes)
732
 E temos algumas opções de SET à escolher:

– Set ip next-hop (especifica o IP de next-hop para o pacote
– deve ser uma subrede diretamente conectada);
– Set ip default next-hop (o mesmo acima, porém, o

roteador tentará antes o roteamento convencional, mas
não usa rota default);
– Set interface (especifica a interface de saída do pacote);
– Set default interface (mesmo acima, porém, o roteador

tentará antes o roteamento convencional, mas não usa
rota default).
733
 Exemplo padrão:
734
 PBR para que pacotes originados pelo PC2 sigam

via R3:
PBR Aplicada para origem

10.1.1.2
735
 Configurações:
R1(config)#interface F0/0
R1(config-if)#ip policy route-map PC2-via-R3
R1(config-if)#exit
R1(config)#route-map PC2-via-R3 permit 10
R1(config-route-map)#match ip address 101
R1(config-route-map)#set ip next-hop 10.1.14.4
R1(config-route-map)#exit
R1(config-if)#access-list 101 permit ip host 10.1.1.2 10.1.3.0 0.0.0.255
736
9.1
PERGUNTAS?
737
9.2 IP SLA Tool
 IP SLA Tool
– O oferecimento de serviços gerenciados vêm se
consolidando como uma tendência já há algum
tempo, e alguns fabricantes disponibilizam algumas
ferramentas que podem nos ajudar a melhorar uma
rede e nos alertar de eventuais problemas, assim
que estes aparecerem.
– Em um mundo em que soluções de IP Telephony e

vídeoconferência IP vêm se tornando parte do dia-a-
dia das empresas, a ferramenta IOS IP SLA pode ser
uma poderosa aliada.
738
9.2 IP SLA Tool
 O IP SLA é um recurso presente em algumas versões

do IOS da Cisco, que permite o gerenciamento
proativo das condições da rede monitorada.
 Basicamente, gera-se um tráfego específico de um
dispositivo (transmitter) com destino a outro
(responder), que responde a este tráfego e medições
são realizadas no decorrer do processo.
 Esta ferramenta torna muito mais simples tarefas como
verificação do correto funcionamento das políticas de
QoS, e também permite certificarmos-nos que
estamos cumprindo os acordos de “uptime”
assinados com o cliente, por exemplo.
739
9.2 IP SLA Tool
 Para habilitar o IP SLA, é necessário configurar ao

menos 2 elementos: O “transmitter” e o
“responder”.
 A configuração do responder é bastante simples (uma
linha de comando, apenas). Ao iniciar a operação, o
transmitter envia mensagens de controle ao
responder.
 Estas mensagens de controle informam ao responder
qual porta lógica (TCP ou UDP) deve ser usada para
as requisições do transmitter. A ativação do serviço
“responder” pode nem ser necessária, se o elemento
que irá responder às solicitações do transmitter já
estiver aguardando dados nas portas a serem
testadas (ex. o serviço HTTP já está ativado no router
740
que agirá comov4.1
responder, e este é o serviço
| autor: Rinaldo Vaz | treinamento.bgp@gmail.com que
queremos “medir”).
9.2 IP SLA Tool
 Este recurso funciona muito bem em diversas

topologias, incluindo topologias “hub & spoke”
(estrela). Neste caso, normalmente, você teria o HUB
como responder, e os spokes como transmitters.
 Uma vez que o serviço SLA esteja devidamente
configurado no transmissor, sua operação precisa ser
agendada.
 As estatísticas apenas serão coletadas quando a
configuração estiver operacional. As atividades de
geração de tráfego e coleta podem ser agendadas
para iniciar de imediato, ou em uma data / hora pré-
determinadas. Podem ainda ser iniciadas sob certas
condições específicas. 741
9.2 IP SLA Tool
 Exemplo: R3#conf t
R3(config)#ip sla {monitor} responder
 Aqui temos OSPF single-area ativado nesta rede, para

garantir conectividade fim-a-fim. Vamos ativar o IP
SLA neste cenário para monitorar um determinado
serviço que roda na porta UDP 1234, de R1 para a
interface Loopback0 de R3. Vamos começar ativando
o IP SLA no responder (R3) :
742
9.2 IP SLA Tool
 Verificando:
R3#show ip sla responder

IP SLAs Responder is: Enabled
Number of Control Message received: 0 Number os errors:0
Recent Sources:
Recent error sources:
743
9.2 IP SLA Tool
 Configurando R1 como “transmiter”:
 Vamos agora configurar o R1 como transmitter,

gerando o tráfego que determinamos para a
loopback de R3 (responder) :
R1(config)#ip sla {monitor} 1
R1(config-ip-sla)#{type} udp-echo 150.1.3.3 1234
R1(config-ip-sla-udp)#frequency 30
 Aqui, criamos uma operação com o ID 1 que gerará um
pacote com destino à porta UDP 1234 ao IP
150.1.3.3 (L0 do responder), à cada 30 segundos.
744
9.2 IP SLA Tool
 Configurando R1 como “transmiter”:
 Vamos iniciar a operação de imediato:
R1(config)#ip sla {monitor} schedule 1 life forever start-time now
745
9.2 IP SLA Tool
 Vamos observar como estão as coisas em R1, nosso

transmitter:
R1#show ip sla {monitor} configuration 1
IP SLAs, Infrastructure Engine-II.
Entry number: 1
Owner:
Tag:
Type of operation to perform: udp-echo
Target address/Source address: 150.1.3.3/0.0.0.0
Target port/Source port: 1234/0
Request size (ARR data portion): 16
Operation timeout (milliseconds): 5000
Operation frequency (seconds): 30 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Threshold (milliseconds): 5000
Distribution Statistics:
[...]
746
9.2 IP SLA Tool
 Vamos observar como está do lado do responder (R3):
R3#show ip sla responder

IP SLAs Responder is: Enabled
Number of control message received: 9 Number of errors: 0
Recent sources:
192.168.12.1 [13:36:17.971 UTC Mon Jun 26 2011]
192.168.12.1 [13:35:47.971 UTC Mon Jun 26 2011]
192.168.12.1 [13:35:17.959 UTC Mon Jun 26 2011]
192.168.12.1 [13:34:47.951 UTC Mon Jun 26 2011]
192.168.12.1 [13:34:17.999 UTC Mon Jun 26 2011]
Recent error sources:
747
9.2 IP SLA Tool
 Agora, vamos associar uma ação ao resultado do IP

SLA... Por exemplo, uma rota estática que apenas
existe se as condições do IP SLA forem atendidas...!!
R1#conf t
R1(config)#track 1 rtr 1 state
R1(config-track)#exit
R1(config)#ip route 123.123.123.0 255.255.255.0 192.168.12.2 track 1
R1#sh ip route static

123.0.0.0/24 is subnetted, 1 subnets
S 123.123.123.0 [1/0] via 192.168.12.2
R1(config)#ip sla {monitor} 1

R1(config-ip-sla)#{type} udp-echo 123.123.123.3 1234
R1(config-ip-sla-udp)#frequency 30
748
9.2 IP SLA Tool
 Como nosso SLA falhou, a rota recém-criada deve sumir

da tabela, já que estava associada à condição do nosso
SLA (track 1 rtr 1):
R3(config)#int l0
R3(config-if)#shutdown
R3(config-if)#
*Jul 28 00:14:11.219: %LINK-5-CHANGED: Interface Loopback0,changed state to administratively down
*Jul 28 00:14:12.219: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
R1#
*Jul 28 00:15:41.671: %TRACKING-5-STATE: 1 rtr 1 state Up->Down
R1#sh ip sla statistics 1
Round Trip Time (RTT) for Index 1
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *00:15:23.031 UTC Mon Jul 28 2008
Latest operation return code: No connection
Number of successes: 9
Number of failures: 1
Operation time to live: Forever
R1#sh ip route 123.123.123.0
% Network not in table
749
9.2 IP SLA Tool
 É possível associar um PBR a uma condição testada pelo

IP SLA Tool, também.
 Eis um exemplo:
set ip next-hop 10.1.14.4
!--- PBR normal, como vimos anteriormente.
set ip next-hop verify-availability 10.1.14.4 1 track 1

!--- Aqui, usamos o parâmetro “verify availability” e associamos o teste para o objeto “1”.
 Enquanto o estado do objeto estiver UP, o PBR funcionará

conforme configurado. Se o objeto em teste mudar de
estado (down), a cláusula “SET” não será executada.
750
9.2
PERGUNTAS?
751
MUITO OBRIGADO!!
752
Posfácio
 100% desse material foi elaborado utilizando software livre, e é

livre para ser copiado e distribuído desde que gratuitamente.
 Está é a versão 4.0 *beta1
 Para reportar erros ou solicitar a versão mais recente entre em
contado por email: rinaldopvaz@gmail.com
 Autor: Rinaldo Vaz
753
CHANGELOG
 CHANGELOG versão 2.2 *beta3 – 3.0:

26/03/2013
● Correções
 Cap 1
 1.1 Initrodução:
 Inseridas informações sobre o MRAI
 mais informações e figuras sobre os tipos de mensagem BGP
 1.1 - Inseridas distâncias administrativas padrão Juniper
 Cap 5
 Corrigidos alguns sub-títulos fora de ordem
(...)
754
CHANGELOG
 CHANGELOG versão 3.0 – 4.0beta9:

24/03/2015
● Correções
 -Quantidade total de slides aumentou de 555 para 760

 -Link com a topologia dos laboratórios
 -Novos gráficos de topologia no início de cada capítulo
 -Mudança no padrão de nomes de host de GX-R1 para AS-X-R1
 -Mudança nos roteadores Cisco c3660 por c7200
 -Mudança de interfaces tipo Serial por interfaces tipo ether e gigabit ethernet
 -Adicionados as plataformas Juniper JunOS, Mikrotik RouterOS, Vyatta VyOS e
Quagga nos laboratórios e material didático
 Os cenários 1 e 2 foram refeitos em apenas um cenário durante todo o treinamento
(...)
755
CHANGELOG

24/03/2015
● Correções
 -Adicionados gráficos nas explicações sobre o processo de escolha de rotas

 -Adicionadas imagens do processo de propagação e instalaçao de rotas
 -Adicionadas imagens demonstrando o fluxo dos pacotes em cada direção
 -Corrigido o bug onde o RS2 não estabelecia BGP no LAB PTT
 -Adicionada a interface Quagga no lugar de cisco no PTT-Looking Glass
 -Adicionado um cliente Mikrotik no laboratório e atualizadas as configurações para
Mikrotik RouterOS no capítulo 4
 - Adicionados mais imagens ilustrativas nos laboratório de Engenharia de Tráfego I
 -Redesenhada toda a topologia do capítulo 5
(...)
756
CHANGELOG

24/03/2015
● Correções
 -Foi triplicado o nível de detalhes nas configurações as sessões iBGP e eBGP,

reduzindo as chances de erros de configuração
 -Foram substituídos os dois clientes cisco por um Juniper e Vyatta no capítulo 5
 -Inserido mais um ponto de troca de tráfego no capítulo 5, onde roteadores
diferentes participam de PTT's diferentes (SP e RJ) e propagam via iBGP.
 -Triplicadas o nível de detalhes e imagens explicativas no laboratório de Engenharia
de Tráfego II
 -Adicionado um novo laboratório no capítulo 7 onde Juniper e Vyatta fornecem
trânsito IP para clientes Quagga
 -Clientes Cisco foram substituídos por Mikrotik nos laboratórios de VPN-Multiponto
(...)
757
CHANGELOG

24/03/2015
● Correções
 -Foram substituídos os dois clientes cisco por um Juniper e Vyatta no capítulo 5

 -Inserido mais um ponto de troca de tráfego no capítulo 5, onde roteadores
diferentes participam de PTT's diferentes (SP e RJ) e propagam via iBGP.
 -Triplicadas o nível de detalhes e imagens explicativas no laboratório de Engenharia
de Tráfego II
 -Adicionado um novo laboratório no capítulo 7 onde Juniper e Vyatta fornecem
trânsito IP para clientes Quagga
 -Adicionado novo capítulo: 9.1 Hardware Sobressalente com VRRP, 9.2-BGP
Timers, reduzindo o tempo de convergência de links
(...)
758
CHANGELOG

24/03/2015
● Correções

 -Adicionado novo capítulo: 9.1 Hardware Sobressalente com VRRP, 9.2-BGP
Timers, reduzindo o tempo de convergência de links
(...)
759
CHANGELOG

26/03/2013
● Correções
(...)
 Pequenas correções enviadas pelo Leonardo Fell
 Slide 17: palavra "implementatos" ("..implementatos por todos os
fabricantes, e quando sim, podem ser..")
 Slide 27: palavra "endendido" no segundo tópico ("O “X” deve ser
endendido como o AS do aluno..")
 Slide 32: plural "os anúncio" na primeira frase
 Slide 36: palavra "provilegiado" e "sesão" no final do slide
 Slide 94 : palavra "analizar" na última frase ("Vamos analizar...")
 Slide 102: palavra "Analizando" na primeira frase
 Slide 143: Palavra "Endendendo" no tópico 3.6
 Slide 168: palavra "trânvito" na última frase
 Slide 174: palavra "infornações" na última frase ("Dessa maneira, todas
as infornações...")
 Slide 192: palavra "acessívels" na última frase
 Slide 303: palavra "Analizando" na primeira frase
760
CHANGELOG

26/03/2013
(...)
– Laboratórios:
● Cenário 2
 Cap 6.3 - Novo laboratório adicionado - "Implementando políticas de
anúncio baseadas em Community-list"
● Outras mudanças
✔ Número total de slides aumentou de 539 para 555
✔ Mudança no layout
✔ Mais figuras explicativas
761
CHANGELOG
 CHANGELOG versão 2.2 *beta2 – 2.2 *beta3:

20/12/2012
● Correções
 Cap 7.3
✔ Inserida linha com o comando “no bgp enforce-fist-as” na configuração
do BGP com o PTT em R1, e nos routers dos AS's 14X e 15X
✔ Inserida linha de comando da rota estática do primeiro /9 apontando para
“Null 0” , o que impossibilitava os routers dos AS's 14X e 15X de
anunciar essa rede para o PTT
● Cap 7.5
✔ Corrigida a ação da as-path access-list 55, onde deny era para ser
permit, e permit era para ser deny
● Cap 8.1
✔ Corrigida a quinta linha na configuração de R5 onde o IP de neighbor era
X.0.0.2, o correto é X.0.0.X
● Cap 8.3
✔ Corrigida a décima linha na configuração de R2, onde o IP a ser
configurado é X.15X.2.1 e não X.15X.2.2
762
CHANGELOG
 CHANGELOG versão 2.2 *beta – 2.2 *beta2:

14/12/2012
● Correções
✗ Laboratórios:
 Cenário 1
✔ Corrigida configuração padrão que mantinha a interface f0/0 desativada
● Cap 7.0
✔ Mudança no indice. Removido PBR que virou um novo capítulo
– Mais conteúdo
● Cap 5.8
✔ Inserido a sessão “cheats” com as respostas do LAB “Desafio”
✔ Inseridos comandos para remover as config do LAB “Desafio”
✔ Número total de slides de 539 para 544
763
CHANGELOG
 CHANGELOG versão 2.1 – 2.2 *beta:

10/12/2012
● Correções
✗ Laboratórios:
 Cenário 1
✔ Corrigida configuração padrão que mantinha a interface f0/0 desativada
– Mais conteúdo
● Inserido um novo capítulo: Multiprotocol Label Switching (MPLS)
● Subcapítulos:
✔ 8.1 BGP através da nuvem MPLS
✔ 8.2 AtoM - Any Transport Over MPLS
✔ 8.3 Implementando serviço VPN-L3 (VPN-Multiponto)
● 6.4 – Manipulando Trânsito (Nacional/Internacional) com Communities
✔ Inserida a relação das communities da GVT
(...)
764
CHANGELOG
 CHANGELOG versão 2.1 – 2.2 *beta:

10/12/2012
(...)
– Laboratórios:
● Cenário 2
– Novo modelo de roteadores para todos o cenário 2 – Cisco 3725
– 2 roteadores a mais para o Lab MPLS VPN-L3, passando de 7 para o
total de 9 roteadoras para cada grupo
✔ Pequenas correções nas confgurações
✔ Mais figuras explicativas
✔ Capítulo 8 (Mecanismos de Path Control) movido para capítulo 9
765
CHANGELOG
 CHANGELOG versão 2.0 – 2.1:

05/10/2012
● Mudança no layout
✔ Cores, fontes e gráficos melhorados
● Correções
✗ Capítulo 4
✗ 4.4 - Expressões regulares
✔ Corrigidas algumas expressões
✔ Conteúdo ampliado com mais exemplos prático
● Mais conteúdo
✗ 4.7 - AS-Path Prepend
✔ Adicionados mais slides com figuras e exemplos de configuração de
prepend de saída
✗ Adicionado um novo slide com exemplo de prepend de entrada
(...)
766
CHANGELOG

05/10/2012
(...)
✔ Inserido um novo capítulo: Mecanismos de Path Control
● Subcapítulos:
– PBR – policy Based Routing
– IP SLA Tool
✔ Pequenas correções nas confgurações
✔ Foram adicinadas mais figuras
✔ Novos slides com configurações que deveriam ser desfeitas antes de iniciar o
próximo laboratório
767
CHANGELOG

26/07/2012
● Mudança no layout
✔ Cores, fontes e gráficos melhorados
● Novos sub-capítulos
✗ Engenharia de tráfego, Alta Disponibilidade, Transporte L2, e outros
● Diversas outras correções
✗ Explicações mais claras
✗ Inseridas mais linhas de comentários explicativos
✗ Melhoradas algumas expressões regulares
✗ Incluídas figuras dos cenários
✗ E muitas outras melhorias
✗ Total de slides aumentados de 363 para 434
768
CHANGELOG

23/04/2012
● 2.6 Slide de abertura do sub-capítulo:

✔ corrigido slide 2.6 trocado pelo 2.7
●
2.7 Corrigido erro de digitação:
✗ erro: "...último /10..."
✔ correção: "... último /9..."
● 3.1 saída do comando "sh ip bgp neighbors (peering) advertise-routes":
✗ corrigidos 2 prefixos que apareciam errados como /10,
✔ o correto são 3 prefixos, um /8 e dois /9
● 3.1 saída do comando "sh ip bgp regexp ^2$":
769
CHANGELOG

23/04/2012
● 2.6 Slide de abertura do sub-capítulo:

✔ corrigido slide 2.6 trocado pelo 2.7
●
2.7 Corrigido erro de digitação:
✗ erro: "...último /10..."
✔ correção: "... último /9..."
● 3.1 saída do comando "sh ip bgp neighbors (peering) advertise-routes":
● 3.1 saída do comando "sh ip bgp regexp ^2$":
770
23/04/2012
● 3.5 Descrição de participante remoto no PTT:

✔ a explicação ficou mais clara com relação às consequências da latência mais alta
● 4.2 Precauções para filtros de UPSTREAMS:
✗ Erro: "... Garantir que rotas de DOWNSTREAMS não recebam prioridade maior..."
✔ Correção: "...Garantir que rotas de UPSTREAMS nao recebam prioridade maior que rotas
DOWNSTREAMS..."
● 4.2 Utilização do (ge) e (le), corrigido erro de digitação:
✗ Erro: "... aceitar qualquer prefixo /25 e descartar..."
✔ Correção: "... aceitar qualquer prefixo /24 e descartar..."
771
23/04/2012
● 4.2 adicionando prefixos na lista "NAO-RECEBER", corrigidos acões de

permit erradas:
● Erro: ...seq 70 permit...
● ...seq 80 permit...
● ...seq 90 permit...
● Correção: ...seq 70 deny...
● ...seq 80 deny...
● ...seq 90 deny...
● 4.6 expressão regular de parcial, modificada para apenas uma linha, e
adicionado um terceiro exemplo para parcial de 3 AS's no path:
✔ nova expressão: ^([0-9]+|[0-9]+ [0-9]+)$
772
23/04/2012
● 4.8 Mudança de título:

✗ Anterior: Manipulando downstream com route-map e prepend
✔ Atual: Manipulando trânsito dos downstreams com prepend
● 6.1 e 6.2 Sub-capítulo sobre expressões regulares:
✔ Movidos de 6.1/6.2 para 4.4/4.5 , 4.4 mudou para 4.6, 4.5 para 4.7, 4.6 para 4.8 e 4.7 para 4.9
● 5.1 Diagrama do cenário 5: Corrigido terceiro octeto da rede dos laptops
✗ Erro: x.x.100.0/24
✔ Correção: x.x.200.0/24
773
23/04/2012
● 5.1 Diagrama do cenário 5:

✔ a partir da versão 1.2 Serão modificados número dos AS's clientes de 11x e 12x para 14x e 15x (para o
grupo 7 ocorria um erro ao utilizar o IP 127.0.0.1)
● 5.1 configurações iBGP, corrigido IP errado na configuração de R1 com R5
✗ Erro:"...neighbor X.0.0.2 remote-as X"
"...neighbor X.0.0.2 description iBGP Router 2
✔ Correção: "...neighbor X.0.0.5 remote-as X"
"...neighbor X.0.0.5 description iBGP Router 5
774
23/04/2012
● 5.1 configuração eBGP com AS 200 (segunda rodada), corrigido endereço

incorreto de neighbor:
✗ erro: "...neighbor 200.X.1.1 remote-as 100"
”...neighbor 200.X.1.1 soft-reconfiguration inbound"
"...neighbor 200.X.1.1 route-map ANUNCIAR-AS-200 out"
✔ correção: "...neighbor 200.X.2.1 remote-as 200"
"...neighbor 200.X.2.1 soft-reconfiguration inbound"
"...neighbor 200.X.2.1 route-map ANUNCIAR-AS-200 out"
● 5.1 Configuração iBGP entre R2 > R3, corrigido número da loopback
faltando
✗ erro: "...neighbor X.0.0.3 update-source loopback "
✔ correção: "...neighbor X.0.0.3 update-source loopback 0"
775
23/04/2012
● 5.1 Configuração iBGP entre R3>todos

✗ erro: alguns IPs errados
✔ correção: corrigidos IPs corretos para R1, R2, R4 e R5
● 6.1 LAB 2, communities padrão
✔ Incluida uma explicação mais clara dos objetivos do LAB
 7.3 Corrigida expressão regular de permitir saida apenas de prefixos
originados ”diretamente” do downstream:
✗ erro: ”_20$”
● forma correta: ”(20_|20$)”
● Adicionadas mais imagens para facilitar a visualização das configurações
776

BGP

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

BGP

Caricato da

Copyright:

Formati disponibili

TREINAMENTO AVANÇADO

BGP Design com Roteadores Cisco,

 Instrutor: Rinaldo Vaz

Versão do material: 4.1

Visão Geral sobre BGP

Topologia dos LABs

neighbor {ip-address | peer-group-name} advertisement-interval seconds

Padrão Cisco* Padrão Juniper*

 A versão corrente do BGP é a versão 4,

neighbor {ip-address | peer-group-name} advertisement-interval seconds

Fonte da imagem: http://www.potaroo.net/ispcol/2005-03/fig1.png

● Ex: Ao receber uma mensagem de “open” com o número

Requisitos para se tornar

Mais informações em:

 Em caso de dúvidas há um arquivo contento

 Informações completas em:

 O BGP foi desenvolvido para troca de rotas

 Caso um dos clientes do provedor também seja

 Conhecidos obrigatórios (Well-known mandatory):

 Conhecidos discricionários (Well-known discretionary):

 Opcional transitivo (Optional transitive):

 Opcional não-transitivo (Optional non-transitive):

 Uma boa descrição pode ser encontrada no livro:

 Em primeiro lugar, o BGP apenas analisa os atributos

 Caso haja um prefixo mais específico esse sempre será

 Como o BGP escolhe uma rota:

1. Rota com maior valor de WEIGHT (Cisco, Quagga, RouterOS, OpenBGPD)

Configurando BGP com

 O router de cada grupo responde pelo IP X.128.0.254/9

Escape character is '^]'.

 Estamos agora no modo ”usuário”:

 Para iniciar as configurações precisaremos inicialmente

 E em seguida no modo de configuração ”global”:

Enter configuration commands, one per line. End with CNTL/Z.

 O router de cada grupo responde pelo IP X.128.0.254/9

Escape character is '^]'.

 O primeiro passo na configuração BGP é adicionar

AS-X-R1(config)# router bgp X

 Verificando o status da sessão BGP recém-criada:

AS-X-R1#sh ip bgp summary

 Como realizar a mesma configuação

[admin@mikrotik] > /routing bgp instance

 Verificando os anúncios que recebo da minha operadora:

AS-X-R1#show ip bgp neighbors 100.X.1.1 routes

 Agora todos tentam ping para 123.123.123.1 a partir do seu

Type escape sequence to abort.

Type escape sequence to abort.

1 100.X.1.1 [AS 100] 16 msec 12 msec 16 msec

 Em seguida ping para 123.123.123.1 a partir do seu laptop

rinaldo@laptop:~$ traceroute 123.123.123.1 -n

 Que problema pode estar havendo?

 Esse ponto merece uma pausa para analisar algo

 Ao executar um traceroute um host verifica a sua tabela de

 Em nosso LAB qual o next-hop para 123.123.123.1 ?

 O IP de origem é 100.X.1.2 que por sua vez está dentro de

 Já o laptop não consegue alcançar o destino porque o seu IP

 Não se trata então de o laptop ”não conseguir alcançar”

 O segundo passo é anunciar o classe A (bloco /8) do seu

 Quando habilitamos o auto-summary, o BGP vai sumarizar na classe

 Algumas literaturas afirmam que o auto-summary não funciona com

 É importante lembrar que esse tipo de sumarização ocorre apenas para

 Agora verifico os anúncios que estou fazendo para o AS 100:

AS-X-R1#sh ip bgp neighbors 100.X.1.1 advertised-routes

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal